Di mana Sistem Kontrol Versi Terdistribusi saat ini berada dalam siklus hype Gartner? [Tutup]

Sunting : Mengingat downvoting baru-baru ini (+ 8 / -6 pada saat ini) jelas bagi saya bahwa siklus hidup Gartner adalah metrik bias dari perspektif programmer. Ini adalah sesuatu yang merupakan bagian dari makalah yang akan saya presentasikan kepada manajemen , dan tipe manajemen adalah bagian dari audiens Gartner.

Memberikan paparan & antusiasme DVCS (yang "bisa" dianggap sebagai hype, atau setidaknya diserang seperti itu ), pikirkan pertanyaan berikut saat membaca yang ini: "bagaimana saya bisa menggunakan siklus hype Gartner untuk meyakinkan manajemen bahwa DVCS siap (atau cukup-siap) untuk kita, dan itu bukan hanya hype "

Hanya dengan bertanya apakah DVCS adalah hype tidak akan konstruktif, siklus hype Gartner adalah instrumen yang lebih objektif daripada hanya menanyakan itu (bahkan jika instrumen ini dianggap bias). Jika Anda tahu instrumen lain, mohon, sebutkan saja.

Sunting # 2 : Saya setuju bahwa Life Cycle Gartner bukan untuk setiap teknologi, tetapi saya menganggapnya mungkin telah menghasilkan buzz yang cukup untuk dianggap hype oleh sebagian orang, jadi mungkin layak untuk setidaknya dievaluasi / dipertimbangkan seperti dengan menggunakan instrumen ini di untuk membuktikan / menyanggahnya sampai tingkat apa pun. Saya seorang advokat dari DVCS, BTW.

Sunting # 3 : Terima kasih atas jawaban Anda. Bounty pergi ke Caleb untuk menjawab pertanyaan saya dengan detail dan saran praktis. Jawaban yang diterima berlaku untuk philosodad karena menyediakan instrumen lain yang bermanfaat dan menjawab di luar pertanyaan saya.

Saya sedang melakukan penelitian untuk whitepaper yang saya tulis mendukung adopsi DVCS di perusahaan dan saya menemukan konsep bukti sosial . Saya ingin membuktikan bahwa bukti sosial adopsi DVCS belum tentu kultus kargo dan melakukan penelitian lebih lanjut saya sekarang menemukan siklus hype Gartner yang menggambarkan kematangan teknologi dalam 5 fase.

Pertanyaan saya adalah: apa yang bisa menjadi indikator lokasi saat ini dari Sistem Kontrol Versi Terdistribusi (maksud saya git, mercurial, bazaar, dll. Secara umum) pada fase tertentu dalam siklus sensasi? ... di lain (kurang berbelit-belit) kata-kata, apakah Anda akan mengatakan bahwa harapan DVCS saat ini adalah a) mulai, b) meningkat, c) menurun (kekecewaan), d) meningkat (pencerahan) atau e) menstabilkan (dewasa) dan (lebih penting) mengapa ?

Saya tahu ini adalah pertanyaan yang sulit dan ada subjektivitas yang terlibat, tetapi saya akan memberikan jawabannya (dan kue tradisional) untuk argumen / bukti paling jelas untuk fase tertentu.

Siklus sensasi mengukur jumlah berita / buzz yang dihasilkan oleh suatu hal, bukan penggunaan aktual dari sesuatu atau itu adalah nilai produktivitas aktual. Jadi ... Saya akan mengatakan bahwa dari perspektif itu, DVCS mencapai lonjakan dalam siklus beritanya. Cukup banyak orang yang benar-benar menggunakannya dan mendorong orang lain untuk menggunakannya sehingga semakin ramai di dunia teknologi. Setelah adopsi semakin meluas, saya berharap berita / buzz sedikit memudar ketika sesuatu yang baru dan berkilau muncul, dan kemudian bangkit kembali ketika orang mulai memahami sistem lebih lengkap.

Salah satu cara untuk melihat siklus sensasi adalah dengan melihat jumlah pengguna baru. Jumlah pengadopsi baru dari suatu teknologi cenderung mengikuti bentuk kurva yang sama persis dengan siklus sensasi. Masuk akal bahwa desas-desus di sekitar teknologi baru akan tumbuh dengan cepat karena teknologi mendapatkan sejumlah besar pengguna baru. Pengadopsi awal menyebarkan inovasi, dan pengadopsi tengah menghasilkan buzz.

Dengung selama adopsi inovasi yang cepat tidak selalu mendapat informasi yang buruk. Jika ada banyak orang yang mengetahui sesuatu tetapi tidak mengetahuinya, mereka akan memiliki harapan yang berbeda dan mungkin lebih besar dari pengguna yang berpengalaman. Jadi dari situlah hype berasal.

Dengungan setelah tingkat adopsi telah memuncak akan jatuh ... sebagian karena sebelumnya, harapan yang tidak realistis belum terbayar (DVCS akan membuat Anda lebih produktif, mungkin, tetapi itu tidak akan memperbaiki semua masalah Anda) dan sebagian karena sesuatu yang lain sedang melalui periode adopsi cepat dan mengambil semua mindshare. Hype berubah-ubah.

Tetapi pada titik tertentu, Anda mulai mendapatkan tingkat pengguna baru yang cukup konstan, inovasi telah menjadi norma, dan pengguna baru ingin tahu cara menggunakan hal ini yang telah mereka putuskan harus mereka gunakan. Kemudian buzz seputar inovasi adalah tentang apa yang sebenarnya dilakukan orang saat menggunakannya, bukan apa yang bisa mereka lakukan jika menggunakannya.

Jadi jika Anda mengambil kurva hype dan meletakkannya di sebelah S-Curve dari tingkat adopsi (Lihat Everett Rogers "Difusi Inovasi"), Anda akan mengharapkan hype memuncak di mana kurva S-curam, melalui sebagai kurva S berubah arah, dan bangkit kembali saat inovasi mencapai kejenuhan pasar penuh.

DVCS berada dalam periode adopsi cepat, jadi kita mungkin berada di sekitar puncak siklus hype.

Saya tidak mengklaim sebagai ahli dalam hal siklus sensasi, tetapi saya akan menawarkan beberapa pengamatan:

1. Siklus hype tampaknya lebih merupakan produk harapan dan liputan media daripada karakteristik teknologi itu sendiri. Kamus saya mengatakan bahwa hype adalah "publisitas atau promosi yang boros atau intensif." Ini mendefinisikan publisitas sebagai "pemberitahuan atau perhatian yang diberikan kepada seseorang atau sesuatu oleh media." Media adalah istilah kolektif untuk berbagai saluran komunikasi massa.

2. Jika Anda menerima poin sebelumnya, maka siklus hype hanya berlaku saat media membahas teknologi tertentu.

3. Sama sekali tidak jelas bahwa siklus sensasi berlaku untuk semua teknologi. Jurnal ilmiah dipenuhi dengan laporan kemajuan yang tidak pernah diperhatikan oleh media arus utama. Tanpa liputan media, ekspektasi kecil kemungkinan akan meningkat dan kekecewaan bisa dihindari.

4. Sistem kontrol versi terdistribusi bukanlah gagasan baru sebagai penyempurnaan dari yang lama. Sangatlah sulit untuk menyebut mereka "teknologi baru" dari jenis yang seharusnya diprediksi oleh siklus sensasi.

Sebelum Anda mulai membangun sebuah kasus untuk mana cocok DVCS pada grafik siklus hype, Anda perlu membangun sebuah kasus yang didistribusikan kontrol versi tunduk pada siklus sensasi sama sekali. Apakah kontrol versi terdistribusi sebagai "teknologi" mendapatkan liputan media? Apakah ada sekarang, atau pernahkah ada, ekspektasi yang meningkat untuk kontrol versi terdistribusi? Apakah mungkin pengguna DVCS akan kecewa ketika produk DVCS tidak memenuhi harapan?

Sepertinya lebih mungkin bagi saya bahwa kontrol versi terdistribusi hanyalah peningkatan pada kategori produk yang ada, seperti halnya SVN merupakan peningkatan pada CVS. Jika Anda memetakan tingkat adopsi SVN, saya tidak berpikir Anda akan mendapatkan plot yang terlihat seperti siklus hype; alih-alih, Anda akan mendapatkan plot yang meningkat terus hingga ke puncak dominasi pasar, diikuti oleh penurunan yang lambat karena sistem yang didistribusikan seperti 'git' mendapatkan popularitas.

Jika Anda benar-benar membutuhkan jawaban hype-cycle, saya akan menyarankan agar DVCS bergabung dengan permainan di bagian bawah periode kekecewaan / frustrasi dengan sistem kontrol versi yang tidak terdistribusi dan telah mendaki lereng pencerahan ketika laju adopsi meningkat.

Alih-alih mengandalkan siklus sensasi untuk argumen Anda, saya sarankan berfokus pada tingkat adopsi kontrol versi terdistribusi dan alasannya. Ada banyak bukti anekdotal bahwa orang-orang beralih ke DVCS karena berfungsi; di sisi lain, saya belum pernah mendengar ada yang beralih kembali ke sistem yang tidak terdistribusi karena mereka kecewa. Untuk mendapatkan data yang sulit, Anda dapat mencoba berbicara dengan perusahaan hosting seperti Beanstalk . Juga, perhatikan interoperabilitas antara sistem terpusat dan sistem terdistribusi. Saya mendengar bahwa 'git' bermain sangat baik dengan SVN. Sistem terpusat terus bekerja dengan cukup baik di ranah korporat, sehingga menekankan "bermain dengan baik"

Perbarui sebagai respons terhadap pengeditan OP:

bagaimana saya bisa menggunakan siklus sensasi Gartner untuk meyakinkan manajemen bahwa DVCS siap (atau cukup siap) [?]

Saya pikir ada beberapa pendekatan yang dapat membantu di sini, dan semua bergantung pada data keras:

Google Trends. Google jelas mengumpulkan banyak data tentang apa yang ada di internet dan apa yang dicari orang. Beberapa hari yang lalu, saya mencari (tetapi tidak bisa menemukan) bukti dari siklus hype wrt didistribusikan kontrol versi. http://trends.google.com/ mengatakan bahwa tidak ada cukup data untuk istilah dvcs atau kontrol versi terdistribusi ketika saya membatasi wilayah ke AS (dan hasil dvcs untuk dunia tampaknya tidak terlalu relevan atau membantu). Mencari istilah yang lebih spesifik agak lebih baik, tetapi rumit oleh fakta bahwa nama produk seperti git dan lincah memiliki arti lain (siapa yang tahu?). Hasil untuk git menunjukkan tren yang mungkin sebagian disebabkan oleh sistem kontrol versi:

Mencoba membuatnya lebih spesifik untuk kontrol versi, saya mencoba repositori git :

Satu lagi ... mencari tahu bahwa jika orang mengadopsi git harus ada tren yang meningkat dalam mencari bantuan dengan perintah git, saya mencoba git pull (biru), git commit (merah), dan git rebase (emas):

Grafik terakhir itu tampaknya memberikan bukti terbaik bahwa orang mengadopsi dan menggunakan git.

Pencarian Google.

Coba hanya mencari istilah seperti kontrol versi terdistribusi dan catat tanggal pada, katakanlah, 25 artikel teratas yang Anda temukan. Plot hasilnya. Sebagian besar lagu top yang saya temukan memiliki tanggal dalam rentang 2007-2009. Jika siklus hype berlaku, dan jika Anda dapat menunjukkan bahwa sebagian besar liputan media terjadi 3-5 tahun yang lalu, itu sepertinya bukti yang cukup bagus bahwa kami telah bergerak melampaui puncak ekspektasi yang meningkat.

Kumpulkan contoh-contoh proyek yang menggunakan DVCS.

Ada banyak contoh di dunia open source, termasuk beberapa yang besar seperti Linux. (Linus Torvalds menciptakan git untuk membantu mengelola pengembangan Linux.) Yang lebih bermanfaat bagi Anda adalah contoh perusahaan yang menggunakan DVCS. (Jika ada sesuatu yang lebih dibenci manajer daripada mengadopsi teknologi terlalu dini, itu sudah ketinggalan zaman.) Hype hanya itu - desas-desus tentang teknologi atau produk. Jika Anda dapat menemukan bukti adopsi DVCS perusahaan, itu akan membantu melawan argumen "itu hanya banyak sensasi" mungkin lebih baik daripada yang lain.

Kiat terakhir:

• Lebih spesifik. Perusahaan Anda tidak akan mengadopsi seluruh teknologi - Anda akan mengadopsi produk tertentu. Beberapa produk selalu kurang matang dibandingkan yang lain. Pilih dua atau tiga produk DVCS yang terkenal dan tunjukkan bagaimana masing-masing produk akan sesuai dengan proses pengembangan Anda. Manajer menyukai ide konkret lebih baik daripada janji yang tidak jelas, jadi menganalisis teknologi dalam istilah tertentu akan membuat mereka merasa lebih nyaman.

• Bukan semuanya atau tidak sama sekali. Setiap proyek nyata menggunakan DVCS masih akan memiliki repositori pusat, sehingga kekhawatiran tentang kehilangan kendali atas perhiasan mahkota dapat dengan mudah diredakan.

• Tidak perlu melepaskan sistem Anda saat ini. Beberapa alat, seperti git, dapat bermain dengan baik dengan sistem kontrol versi yang ada, seperti svn. Jadi Anda dapat dengan mudah menambahkan DVCS ke proses pengembangan Anda tanpa menyerah.

• Mulai dari yang kecil. Kecuali Anda berada di perusahaan kecil yang hanya memiliki satu proyek, akan mudah untuk memasukkan DVCS ke dalam proses hanya satu atau dua proyek Anda. Anda tidak harus melompat-lompat terlebih dahulu - cukup celupkan jari kaki.

Singkatnya, identifikasi poin-poin perlawanan dan atasi dengan sejelas mungkin.

argumen / bukti dari fase tertentu

Apa pun fase itu, itu haruslah yang cocok dengan fakta bahwa teknologi digunakan secara profesional selama "lebih dari 10 tahun" , karena VWS TeamWare yang didistribusikan telah ada lebih dari itu: Panduan Pengguna pdf yang disebutkan di bawah ini bertanggal Juli 2001 .

Per Wikipedia, penyebaran TeamWare terbesar adalah di dalam Sun sendiri, di mana (kecuali beberapa pengecualian) pada satu titik itu adalah satu-satunya VCS yang digunakan - yang membuat ribuan pengembang menggunakan alat ini. TeamWare telah digunakan untuk mengelola pohon sumber terbesar Sun, termasuk yang untuk sistem operasi Solaris dan sistem Java .

Artikel Wikipedia mengacu pada pesan Usenix dari Evan Adams, yang merupakan pemimpin arsitektur untuk TeamWare, yang secara khusus menyatakan:

Pada musim semi 1991 kami memutuskan untuk mengimplementasikan proyek TeamWare ...

TeamWare adalah seperangkat baris perintah dan alat GUI yang dibangun dari beberapa perpustakaan umum. Perpustakaan disediakan oleh grup TeamWare untuk digunakan oleh aplikasi TeamWare; mereka tidak disediakan untuk penggunaan yang lebih umum.

TeamWare adalah produk manajemen kode yang mendorong pengembangan paralel dan dibangun di atas SCCS. Seorang pengguna membuat salinan (serah terima) dari hierarki SCCS sehingga menciptakan hierarki pribadi. Dalam hierarki ini pengguna membuat dan menguji perubahan. Perubahan ini kemudian diintegrasikan (putback) ke dalam hierarki asli. Jika hierarki integrasi berisi perubahan yang tidak ada dalam hierarki pengguna, maka TeamWare mendeteksi bahwa ada perubahan paralel dan menolak integrasi. Oleh karena itu, pengguna harus memasukkan perubahan dalam hierarki integrasi ke dalam hierarki mereka sendiri sebelum diintegrasikan. TeamWare juga menyertakan utilitas filemerge, program perbedaan tiga arah grafis yang memungkinkan pengguna untuk menggabungkan perubahan paralel. TeamWare melacak perubahan file sumber (SCCS delta) dan mengubah nama file ...

Jika Anda tertarik, temukan detail lebih lanjut di sini:

• "The Old Man and the C" oleh Evan Adams
• "Panduan Pengguna Sun WorkShop TeamWare" di situs Oracle / Sun - pdf ^{Juli 2001} , html

^{Per ingatan saya, CVS / SVN terpusat saat itu memiliki keuntungan untuk dapat berjalan di Windows dan Linux, sementara TeamWare (SCCS) telah dikunci dalam sistem file Solaris (di Linux itu berjalan lebih atau kurang, jika ada yang tahu cara meretas bug "zero checksum" palsu).}

Jawabanku:

Saya pikir jawabannya ada di suatu tempat antara "Internet TV" dan "Cloud Computing" di bahu "Peak of Inflated Expectations" (Meskipun saya pikir keduanya telah bergerak agak cepat dalam beberapa tahun terakhir).

Sifat siklus sensasi:

Seperti yang saya pahami, perkembangan melalui siklus sensasi dicirikan oleh kesadaran yang berkembang tentang pro dan kontra dari teknologi tertentu, bukan oleh ukuran obyektif "kematangan" (apa pun artinya).

Sebelum kita mengumpulkan seperangkat pengalaman yang cukup beragam untuk membangun opini yang seimbang (dan independen ), dinamika kerumunan (secara alami) bergoyang, dengan opini yang sangat berkorelasi dengan sedikit keragaman, kehalusan atau kedalaman analisis.

Ini sama benarnya dalam "Palung Kekecewaan" seperti halnya dalam "Puncak Ekspektasi yang Meningkat"

Jika masyarakat menghasilkan berbagai pendapat yang luas dan beragam, dengan analisis mendalam tentang di mana dan kapan DVCS layak digunakan dan di mana dan kapan tidak, maka kita dapat menyimpulkan bahwa kita berada di "Dataran Tinggi Produktivitas" (Atau setidaknya beberapa cara menaiki "Lereng Pencerahan").

Jika, di sisi lain, wacana difokuskan pada superioritas (atau sebaliknya) suatu teknologi tanpa memperhatikan kemiringan dan lipatan dari lanskap kompetitif tempat ia berdiri, maka kita dapat menyimpulkan bahwa kita berada pada "Puncak Ekspektasi yang Meningkat "atau" Palung Kekecewaan ". Kita bahkan bisa berada di kedua fase pada saat yang sama, jika komunitas dibagi ke dalam kamp oleh perang api.

:-)

Evaluasi DVCS sesuai dengan kriteria ini:

Dari analisis yang relatif dangkal yang telah saya lihat dalam wacana sejauh ini, dan relatif tidak adanya komentar negatif, saya akan memperkirakan bahwa kami saat ini sedang mendaki "Puncak Ekspektasi Melambung", dengan pertanyaan (seperti ini) yang menunjukkan bahwa ada ada beberapa yang sedang mempersiapkan lereng di sisi lain.

Saya pikir indikator kuat dari kematangan teknologi DVCS (dari sudut pandang korporat) adalah ketika perdebatan bergeser dari sekadar bertanya "Mengapa DVCS?" to "Bagaimana kita bisa menyusun alur kerja dan proses terbaik di sekitar DVCS untuk memaksimalkan manfaat bagi organisasi?".

Dari apa yang saya lihat, kita belum semuanya. (Meskipun beberapa rekan kami yang lebih canggih memimpin jalan)

Peran Siklus sensasi dalam pengambilan keputusan:

Model "Hype Cycle" adalah model bias perilaku, dan ini membantu kita memahami keadaan mental kita sendiri. Jika kita dapat menentukan bahwa suatu teknologi dihipnotis oleh orang lain, maka itu dapat memengaruhi sikap mental kita sendiri, dan (dengan risiko pemikiran ganda) kita mungkin perlu memberikan kompensasi dan memaksa diri kita untuk berperilaku rasional dalam memilih kriteria seleksi kita.

Kriteria Seleksi:

Tak perlu dikatakan, pilihan kriteria seleksi sangat tergantung pada konteks.

Secara pribadi saya akan melakukan (sebagai semacam latihan curah pendapat) analisis SWOT singkat (15 menit) dari setiap opsi yang Anda pertimbangkan, bersama dengan (serius) analisis PEST situasi untuk memastikan bahwa Anda membawa lebih luas (non-teknologi) faktor-faktor dalam analisis Anda.

SWOT untuk VCS Terdistribusi

Kekuatan:

• Fleksibilitas - lebih banyak kebebasan untuk memilih alur kerja yang berbeda.
• Kinerja yang lebih baik daripada koneksi jaringan bandwidth rendah / latensi tinggi - lebih baik untuk tim yang didistribusikan & pekerja di luar lokasi.
• Fungsionalitas penggabungan yang lebih canggih, memungkinkan Anda untuk bercabang lebih sering. (Saya tidak yakin ini hal yang baik).
• Kode sumber "dicadangkan" pada setiap mesin pengembang. (Cukup palsu, yang ini, karena dapat mengganggu perencanaan pemulihan bencana yang tepat)

Kelemahan:

• Fleksibilitas - Karena kita memiliki lebih banyak kebebasan untuk memilih alur kerja yang berbeda, kita perlu melakukan pekerjaan tambahan untuk menentukan alur kerja mana yang kita gunakan, dan untuk menegakkannya.
• Kompleksitas & Kesulitan Konseptual (terutama untuk anggota tim non-perangkat lunak-pengembang).

Peluang:

• Mungkin fleksibilitas dapat dimanfaatkan untuk merekayasa alur kerja yang lebih sesuai dengan kebutuhan bisnis?

Ancaman:

• Mungkin kita akan menghabiskan begitu lama merekayasa ulang alur kerja kita sehingga kita akan kehilangan fokus pada produk inti kita?
• Mungkin sulit untuk membuat beberapa orang menggunakan bahkan alat sederhana, terutama jika mereka tidak percaya bahwa mereka diperlukan atau sebaliknya tidak termotivasi.

SWOT untuk VCS Terpusat

Kekuatan:

• Menyediakan saluran komunikasi implisit in-band untuk organisasi & proses bisnis.
• Membatasi alur kerja yang mungkin untuk subset (dalam banyak kasus masuk akal).
• Mempermudah mengatur CI & alat otomasi pengembangan lainnya.
• (Khusus SVN) Mendukung repositori besar.
• (Khusus SVN) Sangat stabil, digunakan oleh banyak organisasi besar dan konservatif.
• Secara politis lebih dapat diterima dalam organisasi perintah & kontrol top-down?

Kelemahan:

• Tidak fleksibel.
• Kinerja buruk dibandingkan koneksi bandwidth rendah / latensi tinggi, membuatnya lebih sulit untuk digunakan untuk tim yang didistribusikan dan pekerja di luar lokasi (terutama jika repositori menjadi besar)

Peluang:

• Mungkin kita dapat menggunakan sifat repositori monolitik untuk membantu pengembang menavigasi produk dan menggunakan kembali kode masing-masing lebih banyak?

Ancaman:

• Jika proyek tiba-tiba menjadi sangat penting dan kita perlu memasukkan pengembang tambahan yang bekerja di situs lain, dapatkah mereka bekerja secara efektif dengan repositori SVN yang dihosting (untuk mereka) di luar lokasi?
• Jika himpunan pengembang tumbuh begitu besar sehingga mengoordinasi mereka menjadi sulit, akankah repositori terpusat tunggal menjadi hambatan? (Bisakah kita menyiasati ini dengan cara lain?)

Kesimpulan:

VCS mana yang digunakan tergantung pada keadaan individu. Untuk banyak situasi di mana saya telah bekerja, DVCS dengan alur kerja terpusat akan baik-baik saja, tapi saya harus membenarkan waktu & upaya untuk membangun mekanisme untuk mendukung dan menegakkan alur kerja, yang seharusnya (masih susah.

Pada akhirnya, saya pikir diskusi harus berpusat pada pertanyaan: Alur kerja apa yang paling cocok untuk bisnis kita? Alat terbaik untuk digunakan harus mengikuti secara alami dari jawaban untuk pertanyaan itu.