ปัจจุบันระบบควบคุมเวอร์ชันแจกจ่ายอยู่ที่ไหนในรอบ hype ของ Gartner [ปิด]

แก้ไข : จากการ downvoting ล่าสุด (+ 8 / -6 ณ จุดนี้) มันชัดเจนสำหรับฉันว่าวงจรชีวิตของ Gartner เป็นตัวชี้วัดเอนเอียงจากมุมมองของโปรแกรมเมอร์ นี่คือสิ่งที่เป็นส่วนหนึ่งของบทความที่ฉันจะนำเสนอต่อฝ่ายบริหารและประเภทการจัดการเป็นส่วนหนึ่งของผู้ชมของการ์ทเนอร์

การเปิดรับ DVCS & ความกระตือรือร้น (ซึ่ง "ถือว่า" ถือว่าขัดต่อความเป็นจริงหรืออย่างน้อยก็ถูกโจมตี ) ให้คิดถึงคำถามต่อไปนี้เมื่ออ่านคำถามนี้: "ฉันจะใช้วงจร hype ของ Gartner อย่างไรเพื่อโน้มน้าวให้ฝ่ายบริหารจัดการว่า DVCS นั้นพร้อมแล้ว (หรือ พร้อมแล้ว) สำหรับเราและมันไม่ใช่แค่โฆษณา "

เพียงแค่ถามว่า DVCS นั้นเป็น hype จะไม่สร้างสรรค์หรือไม่วัฏจักรของ hype ของ Gartner เป็นเครื่องมือที่มีวัตถุประสงค์มากกว่าการถาม (แม้ว่าเครื่องมือนี้จะถือเป็นลำเอียง) หากคุณรู้จักเครื่องดนตรีอื่นโปรดได้โปรดพูดถึงมัน

แก้ไข # 2 : ฉันยอมรับว่าวัฏจักรชีวิตของ Gartner นั้นไม่ได้มีไว้สำหรับทุกเทคโนโลยี แต่ฉันคิดว่ามันน่าจะสร้างความฮือฮามากพอที่จะนำมาพิจารณาโดยบางคนดังนั้นจึงสมควรสมควรที่จะได้รับการประเมิน / ไตร่ตรองอย่างน้อย เพื่อพิสูจน์ / พิสูจน์หักล้างไม่ว่าจะในระดับใด ฉันเป็นผู้สนับสนุนของ DVCS, BTW

แก้ไข # 3 : ขอบคุณสำหรับคำตอบของคุณ เงินรางวัลไปที่ Caleb เพื่อตอบคำถามของฉันพร้อมรายละเอียดและคำแนะนำที่เป็นประโยชน์ คำตอบที่ได้รับการยอมรับไปที่ philosodad สำหรับการจัดหาเครื่องมือที่มีประโยชน์และตอบคำถามของฉัน

ฉันทำวิจัยสำหรับเอกสารที่ผมเขียนในความโปรดปรานของการยอมรับ DVCS ที่ บริษัท และฉันสะดุดเข้ากับแนวคิดของหลักฐานทางสังคม ฉันต้องการพิสูจน์ว่าหลักฐานทางสังคมของการยอมรับ DVCS นั้นไม่จำเป็นต้องเป็นลัทธิการขนส่งสินค้าและการวิจัยเพิ่มเติมที่ฉันได้พบกับวงจร hypeของการ์ทเนอร์ซึ่งอธิบายถึงวุฒิภาวะของเทคโนโลยีในระยะที่ 5

คำถามของฉันคืออะไรอาจเป็นตัวบ่งชี้ที่ตั้งปัจจุบันของระบบควบคุมเวอร์ชันแจกจ่าย (ฉันหมายถึง git, mercurial, bazaar, ฯลฯ โดยทั่วไป) ที่ระยะใดช่วงหนึ่งในวัฏจักร hype? ... ในอื่น ๆ (ที่ซับซ้อนน้อยกว่า) คำคุณจะบอกว่าปัจจุบันความคาดหวังของ DVCSs เป็น) เริ่มต้น, b) ที่สูงเกินจริง, c) ลดลง (ความท้อแท้), d) เพิ่มขึ้น (ตรัสรู้) หรือ e) เสถียรภาพ (ผู้ใหญ่) และ (ที่สำคัญกว่า) ทำไม ?

ฉันรู้ว่ามันเป็นคำถามที่ยากและมีความเกี่ยวข้องกับเรื่องส่วนตัว แต่ฉันจะให้คำตอบ (และคุกกี้แบบดั้งเดิม) กับการโต้แย้ง / หลักฐานที่ชัดเจนที่สุดสำหรับระยะใดช่วงหนึ่ง

วัฏจักร hype เป็นการวัดปริมาณข่าว / เรื่องปากต่อปากที่สิ่งใดสิ่งหนึ่งสร้างขึ้นไม่ใช่การใช้งานจริงของสิ่งนั้นหรือเป็นมูลค่าการผลิตที่แท้จริง ดังนั้น ... ฉันจะบอกว่าจากมุมมองดังกล่าว DVCS กำลังพุ่งสูงขึ้นในรอบข่าว ผู้คนมากพอที่จะใช้มันและกระตุ้นให้คนอื่นใช้มันว่ามันได้รับความนิยมอย่างมากในโลกของเทคโนโลยี เมื่อการยอมรับเป็นที่แพร่หลายมากขึ้นฉันคาดหวังว่าข่าว / ข่าวลือจะจางหายไปเล็กน้อยเมื่อมีสิ่งใหม่และเงางามเข้ามาแล้วลุกขึ้นมาอีกครั้งเมื่อผู้คนเริ่มเข้าใจระบบมากขึ้นอย่างสมบูรณ์

วิธีหนึ่งในการดูรอบ hype คือดูจำนวนผู้ใช้ใหม่ จำนวนผู้ใช้งานใหม่ของเทคโนโลยีมีแนวโน้มที่จะปฏิบัติตามรูปร่างโค้งที่แน่นอนเช่นเดียวกับรอบ hype มันสมเหตุสมผลแล้วที่เสียงพึมพำกับเทคโนโลยีใหม่ที่กำหนดจะเติบโตอย่างรวดเร็วเนื่องจากเทคโนโลยีได้รับผู้ใช้ใหม่จำนวนมาก ผู้ใช้งานในช่วงแรกกระจายนวัตกรรมและผู้ใช้งานระดับกลางจะสร้างข่าวลือ

เสียงกระหึ่มในระหว่างการนำนวัตกรรมมาใช้อย่างรวดเร็วนั้นเป็นสิ่งจำเป็นอย่างยิ่ง หากมีคนจำนวนมากที่รู้บางสิ่ง แต่ไม่รู้เกี่ยวกับสิ่งนั้นพวกเขาจะมีความคาดหวังที่แตกต่างและอาจมากกว่าผู้ใช้ที่มีประสบการณ์ นั่นคือที่มาของโฆษณา

เสียงกระหึ่มหลังจากอัตราการยอมรับเป็นไปได้ที่จะลดลง ... ส่วนหนึ่งเป็นเพราะก่อนหน้านี้ความคาดหวังที่ไม่สมจริงไม่ได้ชำระ (DVCS จะทำให้คุณมีประสิทธิผลมากขึ้นบางที แต่มันจะไม่แก้ไขปัญหาทั้งหมดของคุณ) และอีกส่วนหนึ่งเพราะ บางสิ่งบางอย่างกำลังจะผ่านช่วงเวลาการรับเลี้ยงบุตรบุญธรรมอย่างรวดเร็วและใช้ความคิดทั้งหมด Hype ไม่แน่นอน

แต่ในบางจุดคุณเริ่มได้รับอัตราที่ค่อนข้างคงที่สำหรับผู้ใช้ใหม่นวัตกรรมกลายเป็นบรรทัดฐานและผู้ใช้ใหม่ต้องการทราบวิธีใช้สิ่งนี้ที่พวกเขาตัดสินใจแล้วว่าต้องการใช้ ถ้าอย่างนั้นเสียงกระหึ่มรอบนวัตกรรมคือทั้งหมดที่เกี่ยวกับสิ่งที่ผู้คนกำลังทำกับมันตอนนี้ว่าพวกเขากำลังใช้มันมากกว่าสิ่งที่พวกเขาสามารถทำได้ถ้าพวกเขาใช้มัน

ดังนั้นถ้าคุณเอาเส้นโค้ง hype และวางไว้ถัดจากอัตราการยอมรับ S-Curve (ดู Everett Rogers "การแพร่กระจายของนวัตกรรม") คุณคาดหวังว่า hype จะสูงสุดที่เส้นโค้ง S นั้นชันมากที่สุดเนื่องจากการเปลี่ยนแปลงของเส้นโค้ง S ทิศทางและเพิ่มขึ้นอีกครั้งเมื่อนวัตกรรมมาถึงความอิ่มตัวของตลาดอย่างเต็มรูปแบบ

DVCS อยู่ในช่วงที่มีการนำไปใช้อย่างรวดเร็วดังนั้นเราจึงอาจอยู่แถว ๆ จุดสูงสุดของวัฏจักรโฆษณา

ฉันไม่ได้อ้างว่าเป็นผู้เชี่ยวชาญในเรื่องของ hype cycles แต่ฉันจะเสนอข้อสังเกตบางประการ:

1. วัฏจักรโฆษณาดูเหมือนจะเป็นผลมาจากความคาดหวังและความครอบคลุมของสื่อมากกว่าลักษณะของเทคโนโลยีเอง พจนานุกรมของฉันบอกว่าhypeนั้นคือ "การประชาสัมพันธ์หรือการส่งเสริมการขายที่มากเกินไปหรือมากเกินไป" มันกำหนดการประชาสัมพันธ์เป็น "การแจ้งเตือนหรือความสนใจให้กับใครบางคนหรือบางสิ่งบางอย่างจากสื่อ" สื่อเป็นคำศัพท์ที่ใช้ร่วมกันสำหรับช่องทางการสื่อสารมวลชนที่หลากหลาย

2. หากคุณยอมรับจุดก่อนหน้านี้จะเป็นไปตามวัฏจักรโฆษณาซึ่งจะมีผลเฉพาะเมื่อสื่อครอบคลุมเทคโนโลยีที่กำหนด

3. ไม่ชัดเจนเลยว่าวงจรโฆษณานี้ใช้กับเทคโนโลยีทั้งหมด วารสารวิทยาศาสตร์เต็มไปด้วยรายงานความก้าวหน้าซึ่งไม่เคยสังเกตเห็นโดยสื่อกระแสหลัก หากปราศจากการรายงานข่าวของสื่อความคาดหวังมีแนวโน้มที่จะสูงขึ้นน้อยลงและสามารถหลีกเลี่ยงปัญหาความไม่แน่นอนได้

4. ระบบควบคุมเวอร์ชันแบบกระจายนั้นไม่ใช่แนวคิดใหม่ในการปรับแต่งแบบเก่า มันเป็นการยืดที่จะเรียกพวกเขาว่า "เทคโนโลยีที่เกิดขึ้นใหม่" ซึ่งเป็นประเภทที่วงจรโฆษณาควรคาดการณ์

ก่อนที่คุณจะเริ่มสร้างเคสที่เหมาะสมกับ DVCS บนกราฟวงรอบ hype คุณต้องสร้างเคสที่การควบคุมเวอร์ชันแบบกระจายขึ้นอยู่กับวัฏจักร hype เลย การควบคุมเวอร์ชันแบบกระจายเป็น "เทคโนโลยี" ได้รับความครอบคลุมของสื่อหรือไม่ ตอนนี้มีหรือเคยมีความคาดหวังที่สูงเกินจริงสำหรับการควบคุมเวอร์ชันแบบกระจายหรือไม่? เป็นไปได้ไหมที่ผู้ใช้ DVCS จะไม่แยแสเมื่อผลิตภัณฑ์ DVCS ไม่เป็นไปตามความคาดหวัง

ดูเหมือนว่าฉันจะมีความเป็นไปได้มากกว่าที่การควบคุมเวอร์ชันแบบกระจายเป็นเพียงการปรับปรุงหมวดหมู่ของผลิตภัณฑ์ที่มีอยู่เช่นเดียวกับ SVN คือการปรับปรุง CVS ถ้าคุณทำแผนภูมิอัตราการรับเลี้ยงบุตรบุญธรรมของ SVN ฉันไม่คิดว่าคุณจะได้พล็อตที่ดูเหมือนกับวงจรโฆษณา แต่คุณจะได้พล็อตที่เพิ่มขึ้นอย่างต่อเนื่องไปจนถึงที่ราบสูงของการครอบงำตลาดตามมาด้วยการลดลงอย่างช้า ๆ เป็นเวลานานเนื่องจากระบบกระจายเช่นความนิยมของ 'git' ได้รับความนิยม

หากคุณต้องการคำตอบที่เกินจริงฉันขอแนะนำให้ DVCS เข้าร่วมเกมที่ด้านล่างของช่วงเวลาแห่งความท้อแท้ / ความคับข้องใจด้วยระบบควบคุมเวอร์ชันที่ไม่เผยแพร่และได้ปีนความชันแห่งการตรัสรู้ขณะที่อัตราการยอมรับเพิ่มขึ้น

แทนที่จะพึ่งพารอบ hype สำหรับการโต้แย้งของคุณฉันขอแนะนำให้มุ่งเน้นไปที่อัตราการยอมรับของการควบคุมเวอร์ชันกระจายและเหตุผลของมัน มีหลักฐานพอสมควรว่าผู้คนกำลังเปลี่ยนมาใช้ DVCS เพราะมันใช้งานได้ ในทางกลับกันฉันไม่เคยได้ยินใครเปลี่ยนกลับไปเป็นระบบที่ไม่เผยแพร่เพราะพวกเขารู้สึกผิดหวัง เพื่อให้ได้ข้อมูลบางอย่างหนักคุณอาจลองพูดคุยกับ บริษัท โฮสติ้งเช่นถั่ว ยังให้ความสนใจกับการทำงานร่วมกันระหว่างระบบส่วนกลางและระบบกระจาย ฉันได้ยินมาว่า 'git' เล่นได้ดีมากกับ SVN ระบบรวมศูนย์ยังคงทำงานได้ดีในขอบเขตขององค์กรดังนั้นจึงเน้นการ "เล่นเป็นอย่างดีกับ"

อัปเดตตามการแก้ไขของ OP:

ฉันจะใช้วัฏจักรโฆษณาของการ์ตเนอร์เพื่อโน้มน้าวให้ฝ่ายบริหารจัดการว่า DVCS นั้นพร้อมหรือไม่หรือ [พร้อม]

ฉันคิดว่ามีวิธีการไม่กี่วิธีที่สามารถช่วยได้ที่นี่และทั้งหมดพึ่งพาข้อมูลที่ยาก:

Google Trends Google เก็บรวบรวมข้อมูลมากมายเกี่ยวกับสิ่งที่อยู่ในเน็ตและสิ่งที่ผู้คนค้นหา ไม่กี่วันที่ผ่านมาฉันค้นหา (แต่ไม่สามารถหาได้) หลักฐานของ hype cycle wrt การควบคุมเวอร์ชันที่แจกจ่าย http://trends.google.com/บอกว่ามีข้อมูลไม่เพียงพอสำหรับข้อกำหนดdvcsหรือการควบคุมเวอร์ชันแบบกระจายเมื่อฉัน จำกัด ภูมิภาคไปยังสหรัฐอเมริกา (และผลลัพธ์ของdvcsสำหรับโลกดูเหมือนจะไม่เกี่ยวข้องหรือมีประโยชน์มาก) การค้นหาคำที่เฉพาะเจาะจงมากขึ้นนั้นค่อนข้างดีกว่า แต่ซับซ้อนด้วยความจริงที่ว่าชื่อผลิตภัณฑ์เช่นคอมไพล์และMercurialมีความหมายอื่น ๆ (ใครจะรู้?) ผลการคอมไพล์ แสดงแนวโน้มที่อาจเกิดจากระบบควบคุมเวอร์ชัน:

พยายามทำให้เฉพาะเจาะจงมากขึ้นในการควบคุมเวอร์ชันฉันลองใช้ที่เก็บ git :

อีกหนึ่งการหาว่าถ้าผู้คนยอมรับใช้คอมไพล์ควรมีแนวโน้มเพิ่มขึ้นในการค้นหาความช่วยเหลือเกี่ยวกับคำสั่ง git ฉันลองใช้git pull (สีน้ำเงิน), คอมมิทคอม (สีแดง) และรีบูท git (ทองคำ):

กราฟสุดท้ายดูเหมือนว่าจะให้หลักฐานที่ดีที่สุดที่ผู้คนยอมรับและใช้คอมไพล์

ค้นหา Google.

ลองค้นหาคำต่างๆเช่นการควบคุมเวอร์ชันแบบกระจายและจดบันทึกวันที่และบทความ 25 อันดับแรกที่คุณพบ วางแผนผลลัพธ์ ความนิยมสูงสุดที่ฉันพบมีวันที่ในช่วงปี 2550-2552 หากวัฏจักรโฆษณานี้นำไปใช้และหากคุณสามารถแสดงให้เห็นว่าสื่อส่วนใหญ่เกิดขึ้นเมื่อ 3-5 ปีก่อนดูเหมือนว่าจะเป็นหลักฐานที่ดีว่าเราได้ก้าวข้ามความคาดหวังที่สูงเกินจริงไปแล้ว

รวบรวมตัวอย่างของโครงการที่ใช้ DVCS

มีตัวอย่างมากมายในโลกโอเพนซอร์ซรวมถึงตัวอย่างที่ยิ่งใหญ่เช่น Linux (Linus Torvalds สร้างคอมไพล์เพื่อช่วยจัดการการพัฒนาลีนุกซ์) มีประโยชน์มากกว่าสำหรับคุณคือตัวอย่างของ บริษัท ที่ใช้ DVCS (หากมีอะไรที่ผู้จัดการเกลียดมากกว่าการใช้เทคโนโลยีเร็วเกินไปมันก็ล้าหลัง) Hype เป็นเช่นนั้น - ข่าวลือเกี่ยวกับเทคโนโลยีหรือผลิตภัณฑ์ หากคุณสามารถหาหลักฐานการยอมรับ DVCS ขององค์กรได้นั่นจะช่วยตอบโต้ข้อโต้แย้ง "มันเป็นเรื่องน่าตื่นเต้นมาก" อาจจะดีกว่าสิ่งอื่นใด

เคล็ดลับสุดท้าย:

• เฉพาะเจาะจง. บริษัท ของคุณจะไม่ใช้เทคโนโลยีทั้งหมด - คุณจะใช้ผลิตภัณฑ์เฉพาะ ผลิตภัณฑ์บางอย่างมักจะเป็นผู้ใหญ่น้อยกว่าผลิตภัณฑ์อื่น เลือกผลิตภัณฑ์ DVCS ที่มีชื่อเสียงสองหรือสามรายการและแสดงว่าผลิตภัณฑ์แต่ละอย่างเหมาะสมกับกระบวนการพัฒนาของคุณอย่างไร ผู้จัดการชอบแนวคิดที่เป็นรูปธรรมดีกว่าคำสัญญาที่คลุมเครือดังนั้นการวิเคราะห์เทคโนโลยีในแง่ที่เฉพาะเจาะจงจะทำให้พวกเขารู้สึกสะดวกสบายมากขึ้น

• มันไม่ใช่ทั้งหมดหรือไม่มีอะไรเลย โครงการจริงใด ๆ ที่ใช้ DVCS จะยังคงมีพื้นที่เก็บข้อมูลส่วนกลางดังนั้นความกลัวเกี่ยวกับการสูญเสียการควบคุมรัตนากรมงกุฎจึงสามารถทำได้อย่างง่ายดาย

• ไม่จำเป็นต้องยกเลิกระบบปัจจุบันของคุณ เครื่องมือบางอย่างเช่น git สามารถเล่นได้ดีกับระบบควบคุมเวอร์ชันที่มีอยู่เช่น svn ดังนั้นคุณสามารถเพิ่ม DVCS ลงในกระบวนการพัฒนาของคุณได้โดยไม่ต้องเสียอะไรเลย

• เริ่มต้นเล็ก ๆ หากคุณไม่ได้เป็น บริษัท เล็ก ๆ ที่มีโครงการเพียงโครงการเดียวคุณควรรวม DVCS ไว้ในกระบวนการสำหรับโครงการของคุณเพียงหนึ่งหรือสองโครงการ คุณไม่ต้องกระโดดเข้าหัวก่อน - แค่จรดเท้า

กล่าวโดยย่อให้ระบุจุดต้านทานและพูดให้ชัดเจนที่สุดเท่าที่จะทำได้

การโต้แย้ง / หลักฐานของแต่ละช่วง

ไม่ว่าจะเป็นช่วงใดก็ตามมันจะต้องเป็นสิ่งที่ตรงกับความจริงที่ว่าเทคโนโลยีมีการใช้งานอย่างมืออาชีพสำหรับ"มากกว่า 10 ปี"เนื่องจากการกระจาย VCS TeamWareอยู่ที่นั่นนานกว่านั้น: คู่มือผู้ใช้ pdf ที่อ้างถึงด้านล่าง .

ตามวิกิพีเดียการปรับใช้ที่ใหญ่ที่สุดของ TeamWare นั้นอยู่ในSunซึ่ง (ยกเว้นข้อยกเว้นบางประการ) ณ จุดหนึ่งเป็น VCS เดียวที่ใช้ - ซึ่งทำให้นักพัฒนาหลายพันรายใช้เครื่องมือ TeamWare ถูกใช้เพื่อจัดการต้นไม้ต้นกำเนิดที่ใหญ่ที่สุดของ Sun รวมถึงต้นไม้ในระบบปฏิบัติการ SolarisและระบบJava

บทความ Wikipedia อ้างถึงข้อความ Usenix จาก Evan Adams ซึ่งเป็นผู้นำด้านสถาปัตยกรรมสำหรับ TeamWare ซึ่งระบุไว้เป็นพิเศษ:

ในฤดูใบไม้ผลิของปี 1991เราตัดสินใจที่จะใช้โครงการ TeamWare ...

TeamWare เป็นชุดของบรรทัดคำสั่งและเครื่องมือ GUI ที่สร้างขึ้นจากห้องสมุดทั่วไปหลายแห่ง ห้องสมุดจัดทำโดยกลุ่ม TeamWare สำหรับใช้งานโดยแอปพลิเคชัน TeamWare พวกเขาไม่ได้ให้ไว้สำหรับการใช้งานทั่วไปมากขึ้น

TeamWare เป็นผลิตภัณฑ์การจัดการรหัสที่ส่งเสริมการพัฒนาแบบขนานและถูกสร้างขึ้นบน SCCS ผู้ใช้ทำสำเนา (นำมา) ของลำดับชั้น SCCS ดังนั้นการสร้างลำดับชั้นส่วนบุคคล ในลำดับชั้นนี้ผู้ใช้สร้างและทดสอบการเปลี่ยนแปลง การเปลี่ยนแปลงเหล่านี้จะถูกรวมเข้าด้วยกัน (putback) ในลำดับชั้นดั้งเดิม หากลำดับชั้นการรวมมีการเปลี่ยนแปลงที่ไม่ได้อยู่ในลำดับชั้นของผู้ใช้ TeamWare ตรวจพบว่ามีการเปลี่ยนแปลงแบบขนานและปฏิเสธการรวม ดังนั้นผู้ใช้จะต้องรวมการเปลี่ยนแปลงในลำดับชั้นการรวมเป็นลำดับชั้นของตนเองก่อนที่จะรวม TeamWare ยังมียูทิลิตี้ filemerge ซึ่งเป็นโปรแกรมความแตกต่างสามทางแบบกราฟิกที่อนุญาตให้ผู้ใช้ผสานการเปลี่ยนแปลงแบบขนาน TeamWare ติดตามทั้งการเปลี่ยนแปลงไฟล์ต้นฉบับ (เดลตา SCCS) และการเปลี่ยนชื่อไฟล์ ...

หากคุณสนใจค้นหารายละเอียดเพิ่มเติมได้ที่นี่:

• "ชายชราและ C"โดย Evan Adams
• "คู่มือผู้ใช้ Sun WorkShop TeamWare" ที่ Oracle / Sun site - pdf ^{กรกฎาคม 2001} , html

^{ตามความทรงจำของฉัน CVS / SVN แบบรวมศูนย์กลับมามีข้อดีของความสามารถในการทำงานบน Windows และ Linux ในขณะที่ TeamWare (SCCS) ถูกล็อกในระบบไฟล์ Solaris (ที่ Linux มันทำงานมากกว่าหรือน้อยกว่าถ้าใครรู้วิธีแฮ็ค ข้อผิดพลาด "zero checksum" ปลอม)}

คำตอบของฉัน:

ฉันคิดว่าคำตอบอยู่ที่ "Internet TV" และ "Cloud Computing" บนไหล่ของ "Peak of Inflated Expectations" (แม้ว่าฉันคิดว่าสิ่งเหล่านี้ทั้งสองเคลื่อนย้ายได้อย่างรวดเร็วในช่วงสองสามปีที่ผ่านมา)

ธรรมชาติของวงจร Hype:

ในขณะที่ฉันเข้าใจมันความก้าวหน้าในวัฏจักรโฆษณานั้นโดดเด่นด้วยการรับรู้การพัฒนาเกี่ยวกับข้อดีข้อเสียของเทคโนโลยีเฉพาะมากกว่าการวัดตามวัตถุประสงค์ของ "วุฒิภาวะ" (ไม่ว่ามันจะหมายถึงอะไร)

ก่อนที่เราจะได้สะสมประสบการณ์ที่หลากหลายอย่างเพียงพอเพื่อสร้างความคิดเห็นที่สมดุล (และเป็นอิสระ ) พลวัตของฝูงชน (ตามธรรมชาติ) จะแกว่งไปแกว่งมาพร้อมกับความคิดเห็นที่มีความสัมพันธ์สูงที่มีความหลากหลายเล็กน้อยความละเอียดหรือการวิเคราะห์เชิงลึก

สิ่งนี้เป็นจริงใน "Trough of Disillusionment" เช่นเดียวกับใน "Peak of Inflated Expectations"

หากชุมชนต้องผลิตความคิดเห็นที่หลากหลายและหลากหลายด้วยการวิเคราะห์เชิงลึกเกี่ยวกับสถานที่และเวลาที่เหมาะสมในการปรับใช้ DVCS และสถานที่และเวลาที่ไม่เมื่อนั้นเราสามารถสรุปได้ว่าเราอยู่ใน "Plateau of Productivity" (หรืออย่างน้อยก็หาทาง "ลาดแห่งการตรัสรู้")

หากในอีกทางหนึ่งวาทกรรมจะเน้นไปที่ความเหนือกว่า (หรืออย่างอื่น) ของเทคโนโลยีโดยไม่คำนึงถึงการลดลงและการพับของแนวการแข่งขันตามที่มันตั้งอยู่จากนั้นเราอาจอนุมานได้ว่าเราเป็นทั้ง "จุดสูงสุดของ ความคาดหวังที่สูงเกินจริง "หรือ" ความท้อแท้ของรางน้ำ " เราอาจอยู่ในทั้งสองขั้นตอนในเวลาเดียวกันหากชุมชนถูกแบ่งออกเป็นค่ายโดยสงครามเปลวไฟ

:-)

การประเมินผลของ DVCS ตามเกณฑ์เหล่านี้:

จากการวิเคราะห์ที่ค่อนข้างตื้นที่ฉันได้เห็นในวาทกรรมจนถึงขณะนี้และการขาดความเห็นเชิงลบฉันจะประเมินว่าเรากำลังปีนขึ้นไปที่ "จุดสูงสุดของความคาดหวังเงินเฟ้อ" โดยมีคำถาม (เช่นนี้) แสดงว่ามี คือบางคนที่กำลังเตรียมความลาดเอียงลงบนอีกด้านหนึ่ง

ฉันคิดว่าตัวบ่งชี้ที่แข็งแกร่งของความเป็นผู้ใหญ่ของเทคโนโลยี DVCS (จากมุมมองขององค์กร) จะเกิดขึ้นเมื่อการอภิปรายเปลี่ยนจากการถามง่ายๆว่า "ทำไมต้องเป็น DVCS" ถึง "เราจะจัดโครงสร้างกระบวนการทำงานและกระบวนการรอบ DVCS ให้เกิดประโยชน์สูงสุดต่อองค์กรได้อย่างไร"

จากสิ่งที่ฉันเห็นเรายังไม่ได้มีทั้งหมด (แม้ว่าเพื่อนร่วมงานที่ซับซ้อนของเราบางคนกำลังนำทางอยู่)

บทบาทของ Hype Cycle ในการตัดสินใจ:

โมเดล "Hype Cycle" เป็นแบบจำลองของพฤติกรรมอคติและช่วยให้เราเข้าใจสภาพจิตใจของเราเอง หากเราสามารถตัดสินได้ว่าเทคโนโลยีนั้นถูกคนอื่นสะกดไว้นั่นอาจส่งผลกระทบต่อจุดยืนทางจิตใจของเราและ (ในความเสี่ยงของการคิดซ้ำซ้อน) เราอาจต้องชดเชยให้เหมาะสมและบังคับให้เราประพฤติปฏิบัติอย่างมีเหตุผลในการเลือกเกณฑ์การคัดเลือกของเรา

เกณฑ์การคัดเลือก:

จำเป็นต้องพูดตัวเลือกเกณฑ์การคัดเลือกนั้นขึ้นอยู่กับบริบทเป็นอย่างมาก

โดยส่วนตัวแล้วฉันจะทำ (เป็นแบบฝึกหัดระดมความคิด) การวิเคราะห์ SWOT สั้น ๆ (15 นาที) ของแต่ละตัวเลือกที่คุณกำลังพิจารณาพร้อมกับ (อย่างจริงจัง) การวิเคราะห์ศัตรูพืชของสถานการณ์เพื่อให้แน่ใจว่าคุณนำที่กว้างขึ้น (ไม่ใช่เทคโนโลยี) ปัจจัยในการวิเคราะห์ของคุณ

SWOT สำหรับ VCS แบบกระจาย

จุดแข็ง:

• ความยืดหยุ่น - อิสระมากขึ้นในการเลือกเวิร์กโฟลว์ที่แตกต่างกัน
• ประสิทธิภาพที่ดีขึ้นผ่านการเชื่อมต่อเครือข่ายที่มีแบนด์วิธต่ำ / ความหน่วงสูงดีกว่าสำหรับทีมงานกระจายและพนักงานนอกสถานที่
• ฟังก์ชันการผสานที่ซับซ้อนมากขึ้นช่วยให้คุณแยกสาขาได้บ่อยขึ้น (ฉันไม่แน่ใจว่านี่เป็นสิ่งที่ดี)
• ซอร์สโค้ดคือ "สำรอง" ในเครื่องนักพัฒนาซอฟต์แวร์แต่ละเครื่อง (เป็นการหลอกลวงอันนี้เนื่องจากอาจรบกวนการวางแผนการกู้คืนความเสียหายที่เหมาะสม)

จุดอ่อน:

• ความยืดหยุ่น - เนื่องจากเรามีอิสระมากขึ้นในการเลือกเวิร์กโฟลว์ที่แตกต่างกันเราจึงต้องทำงานเพิ่มเติมเพื่อกำหนดเวิร์กโฟลว์ที่เรากำลังใช้งานและเพื่อบังคับใช้มัน
• ความซับซ้อน & ความยุ่งยากในการคิด (โดยเฉพาะอย่างยิ่งสำหรับสมาชิกในทีมที่ไม่ใช่นักพัฒนาซอฟต์แวร์)

โอกาส:

• บางทีความยืดหยุ่นสามารถนำไปใช้เพื่อจัดทำเวิร์กโฟลว์ที่เหมาะกับความต้องการทางธุรกิจมากขึ้น?

ภัยคุกคามที่:

• บางทีเราจะใช้เวลาอีกนานในการปรับปรุงกระบวนการทำงานของเราเราจะหลวมมุ่งเน้นผลิตภัณฑ์หลักของเราหรือไม่
• มันอาจเป็นเรื่องยากที่จะทำให้บางคนใช้เครื่องมือง่าย ๆ โดยเฉพาะอย่างยิ่งหากพวกเขาไม่เชื่อว่าพวกเขามีความจำเป็นหรือไม่มีแรงจูงใจ

SWOT สำหรับ VCS รวมศูนย์

จุดแข็ง:

• ให้ช่องทางการสื่อสารโดยนัยในวงดนตรีสำหรับองค์กรธุรกิจและกระบวนการ
• จำกัด เวิร์กโฟลว์ที่เป็นไปได้สำหรับชุดย่อย (ในหลาย ๆ กรณี)
• ทำให้การตั้งค่า CI และเครื่องมืออัตโนมัติอื่น ๆ เพื่อการพัฒนาง่ายขึ้น
• (เฉพาะ SVN) รองรับที่เก็บข้อมูลขนาดใหญ่
• (เฉพาะ SVN) มีเสถียรภาพมากใช้โดยองค์กรขนาดใหญ่และอนุรักษ์นิยมจำนวนมาก
• เป็นที่ยอมรับทางการเมืองมากขึ้นในองค์กรที่สั่งการและควบคุมจากบนลงล่าง?

จุดอ่อน:

• ตาย
• ประสิทธิภาพต่ำผ่านการเชื่อมต่อแบนด์วิธต่ำ / เวลาแฝงสูงทำให้ยากต่อการใช้งานสำหรับทีมงานกระจายและพนักงานนอกสถานที่ (โดยเฉพาะถ้าพื้นที่เก็บข้อมูลมีขนาดใหญ่)

โอกาส:

• บางทีเราสามารถใช้ลักษณะที่เป็นเสาหินเดียวของที่เก็บเพื่อช่วยนักพัฒนานำทางผลิตภัณฑ์และนำรหัสของกันและกันมาใช้ซ้ำได้มากขึ้น?

ภัยคุกคามที่:

• หากโครงการกลายเป็นสิ่งที่มีความสำคัญเกินจริงและเราจำเป็นต้องนำนักพัฒนาเพิ่มเติมมาทำงานในไซต์อื่น ๆ พวกเขาสามารถทำงานกับพื้นที่เก็บข้อมูล SVN ที่โฮสต์ (สำหรับพวกเขา) ได้อย่างมีประสิทธิภาพหรือไม่
• หากชุดของผู้พัฒนาขยายใหญ่ขึ้นจนการประสานงานกลายเป็นเรื่องยากที่เก็บส่วนกลางจะกลายเป็นคอขวดหรือไม่? (เราจะหลีกเลี่ยงวิธีอื่นได้ไหม?)

สรุป:

VCS ใดที่ใช้ขึ้นอยู่กับสถานการณ์ของแต่ละบุคคล สำหรับหลาย ๆ สถานการณ์ที่ฉันทำงาน DVCS ที่มีเวิร์กโฟลว์ส่วนกลางจะทำได้ดี แต่ฉันจะต้องพิสูจน์เวลาและความพยายามในการสร้างกลไกเพื่อสนับสนุนและบังคับใช้เวิร์กโฟลว์ซึ่งจะยังคงอยู่ ยาก.

ท้ายที่สุดฉันคิดว่าการสนทนาควรเน้นไปที่คำถาม: เวิร์กโฟลว์ใดที่เหมาะกับธุรกิจของเรามากที่สุด เครื่องมือที่ดีที่สุดในการใช้ควรทำตามธรรมชาติจากคำตอบของคำถามนั้น