การหาปริมาณข้อดีของระบบควบคุมรุ่นใหม่ [ปิด]

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

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

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

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

ประสบการณ์ของฉันกับผู้บริหารบอกพวกเขาว่าก) ต้องการคำอธิบายสั้น ๆ อย่างยิ่งสำหรับทุกสิ่ง b) สนใจเฉพาะข้อเท็จจริงที่เกี่ยวข้องกับตัวเลขดอลลาร์

สำหรับนักพัฒนาซอฟต์แวร์ฉันสามารถอธิบายข้อดีของ Git ผ่านทาง Clearcase (หรือระบบควบคุมเวอร์ชันอื่น ๆ สำหรับ Clearcase สำหรับเรื่องนั้น) แต่ฉันวาดภาพเปล่า ๆ เกี่ยวกับวิธีการทำสิ่งนี้กับผู้บริหารด้านเทคนิคโดยไม่มีพื้นฐานด้านเทคนิค (เธอมี MBA และปริญญาตรีของเธอในภูมิศาสตร์)

ฉันรู้สึกว่าการโต้เถียงใด ๆ ที่ฉันทำกับเธออาจเป็นไปได้ว่าจะพูดพล่อยๆทางเทคนิคหรือว่าฉันกำลังประกาศเรื่องความชอบส่วนตัว

สิ่งที่ฉันพยายามค้นหาคือข้อเท็จจริงที่เป็นรูปธรรมซึ่งแสดงให้เห็นว่านักพัฒนาทำงานอย่างมีประสิทธิภาพยิ่งขึ้นด้วย Git หรือระบบควบคุมแหล่งข้อมูลสมัยใหม่ใด ๆ

ฉันคิดว่าความจริงที่ว่าทีมอื่น ๆ เริ่มใช้ Git ภายในเป็นสัญญาณที่มีความหมาย แต่ก็ยังไม่แข็งแกร่งพอเพราะมันสามารถถูกไล่ออกได้ตามความชอบส่วนตัว

สิ่งที่ฉันต้องการจริงๆคือสิ่งที่ทรงพลังพอที่จะผ่าน "กระบวนการนี้ได้ทำงานมา 20 ปีทำไมเราต้องเปลี่ยนมัน" ข้อโต้แย้ง.

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

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

จากนั้นสร้างรายการของ "เครื่องมือ" กระบวนการ / เครื่องมือที่ไม่เชื่อเรื่อง Git เท่าที่จะทำได้ (แม้ว่า Git หรือ DVCS สมัยใหม่จะชอบใส่บิลให้ถูกต้อง) การอธิบายว่าทำไม Git ถึงดีกว่า ClearCase ไม่มีความหมายสำหรับผู้ที่ไม่ใช่ผู้ใช้

อนุญาตให้ทีมโครงสร้างพื้นฐานยืนยันว่าแนวทางปัจจุบันมีปัญหาที่คุณระบุ สิ่งนี้อาจนำพวกเขาไปหาการสนับสนุนจาก IBM เพื่อ "แก้ไข" ปัญหาเหล่านี้ ยังคงเชื่อมต่อเพื่อให้แน่ใจว่า IBM ไม่ได้ทำตามขั้นตอนปัญหา เนื่องจาก ClearCase ขาดคุณสมบัติพื้นฐานของความเข้าใจที่ทันสมัยของเราเกี่ยวกับการควบคุมเวอร์ชันปัญหาส่วนใหญ่ไม่สามารถแก้ไขได้หรือจะต้องมีการเปลี่ยนแปลงโครงสร้างพื้นฐานที่สำคัญ

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

โชคดี!

กระบวนการผลิตของเราเป็นฝันร้ายเพราะมันหมุนรอบ Clearcase เรามีกลุ่มการจัดการการเปลี่ยนแปลงที่ดำเนินการเผยแพร่ทั้งหมดและผู้ที่จะอนุญาตให้ใช้รหัสในการผลิตที่นำมาจากมันเท่านั้น

ไม่กระบวนการของคุณเป็น "ฝันร้าย" เนื่องจากกลุ่มการจัดการการเปลี่ยนแปลงและขั้นตอนการเผยแพร่ของคุณ ไปข้างหน้าและแทนที่ Clearcase สำหรับ SVN หรือ git หรือ Fossil คุณจะมีปัญหาเดียวกันแน่นอน (ฉันคิดว่าพวกเขาทำถูกต้อง TBH การควบคุมการเปิดตัวที่แข็งแกร่งเป็นสิ่งจำเป็น)

นี่คือสิ่งที่คุณต้องมุ่งเน้นไม่ใช่ข้อมูลประจำตัวที่น่ามองของ git (ซึ่งไม่เกี่ยวข้องกับทุกคนยกเว้น devs) คุณจำเป็นต้องมุ่งเน้นไปที่กรณีศึกษาทางธุรกิจเพื่อเปลี่ยนกระบวนการให้เป็นภาระน้อยกว่า โอกาสที่คุณสามารถทำได้โดยใช้ Clearcase แต่มันให้โอกาสคุณที่จะแอบคิดในการใช้คอมไพล์

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

แนวคิดบางประการสำหรับคุณ: ให้พวกเขาเห็นปัญหาด้านประสิทธิภาพการทำงานของระบบปัจจุบันจากมุมมองของนักพัฒนา ทำเช่นนี้เป็นส่วนที่ 1 จาก 2 ส่วนที่ 2 ไปและทำงานร่วมกับพวกเขาในการเปิดตัวเพื่อให้คุณสามารถเห็นปัญหาการควบคุมที่นักพัฒนาของคุณต้องเข้าใจ ถือว่าเป็นแบบฝึกหัดการเรียนรู้สำหรับทั้งสองฝ่ายเพื่อดูมุมมองของอีกด้านหนึ่งและจากนั้นคุณควรจะสามารถหาวิธีแก้ปัญหาที่ยังคงแก้ปัญหาที่สำคัญ ๆ ได้ โปรดทราบว่าการเปิดตัวมีความสำคัญมากกว่าการพัฒนาดังนั้นคุณควรเป็นคนที่เตรียมที่จะให้มากกว่าที่คุณคาดหวัง

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

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

หากคุณสามารถแนบช่วงเวลาและวันที่ที่เฉพาะเจาะจงกับตัวอย่างเหล่านี้ได้ดียิ่งขึ้น คุณอาจจะสามารถปิดเรื่องนี้ได้ด้วยการแสดงภารกิจ X ที่คุณต้องทำมากใช้เวลา Y นาทีใน Clearcase และ Z นาทีใน Git

โปรดจำไว้ว่าเวลานั้นเป็นเงินดังนั้นหากคุณสามารถแสดงให้เห็นว่าการทำงานกับ Git นั้นเร็วขึ้นคุณสามารถแสดงให้เห็นว่ามันจะสร้างความรู้สึกทางการเงิน

นี่คือความพยายามในวิธีที่ฉันจะลองสิ่งนั้น

นั่นอาจฟังดูโง่สำหรับนักพัฒนา แต่สำหรับการจัดการการเปลี่ยนแปลงทางเทคโนโลยีถือเป็นความเสี่ยง

"ถ้าสิ่งมหัศจรรย์ใช้งานได้แล้วทำไมถึงเสี่ยงที่จะทำลายมัน"

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

ฉันจะเริ่มต้นด้วยการพูดว่าคอมไพล์ตอนนี้ใช้กันอย่างแพร่หลาย ใช้ตัวเลขเช่นเดียวกับที่: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

สำหรับผู้จัดการนี่หมายความว่าพวกเขาควรจะสามารถพบนักพัฒนามากมายที่ใช้ git และระบบนิเวศทั้งหมดของเครื่องมือของบุคคลที่สาม (ฉันได้ยินแม้กระทั่ง Microsoft รวม git เข้ากับ visual Studio แล้ว)

นอกจากนี้ผู้จัดการไม่สามารถถูกตำหนิสำหรับการติดตามสิ่งสำคัญพวกเขาได้หรือไม่ ในทางกลับกันใครใช้ $ other_cvs ที่นี่

ให้ความสำคัญกับโครงการขนาดใหญ่ที่ใช้งานเพราะง่ายรวดเร็วยืดหยุ่นและมีประสิทธิภาพ ... ค้นหาโครงการขนาดใหญ่ที่มีชื่อขนาดใหญ่แนบมา (GNU / Linux, Google, Microsoft ... ) ที่ใช้คอมไพล์

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

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

ฉันจะสรุปสิ่งที่เหมาะสมทั้งหมดลงในอีเมลที่เป็นลายลักษณ์อักษรหลังจากการประชุม (รวมถึงบุคคลที่เหมาะสม)

สิ่งที่ฉันต้องการจริงๆคือสิ่งที่ทรงพลังพอที่จะผ่าน "กระบวนการนี้ได้ทำงานมา 20 ปีทำไมเราต้องเปลี่ยนมัน" ข้อโต้แย้ง.

นี่เป็นข้อโต้แย้งที่ไม่ถูกต้อง (รถม้าที่ลาก "ทำงานมาหลายศตวรรษแล้ว" แต่คุณอาจต้องการซื้อรถแทน)

ฉันเคยได้ยินเรื่องเดียวกันเกี่ยวกับ svn กับ mercurial (ฉันเป็นคนที่ใช้ mercurial ในระบบการพัฒนาของฉัน)

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

ข้อโต้แย้งที่ดีสำหรับการใช้คอมไพล์:

• git คือ Centet การเปลี่ยนแปลงแทนไฟล์เป็นศูนย์กลาง ซึ่งหมายความว่าการเปลี่ยนแปลงจะง่ายกว่าในการติดตามไฟล์ข้าม (ติดตามได้ตามโครงการ)

• git ถูกแจกจ่ายแทนการรวมศูนย์ ซึ่งหมายความว่าการตรวจสอบสิ่งต่าง ๆ ไม่ได้ถูก จำกัด ด้วยความเร็วเครือข่าย - ประหยัดเวลาได้มากอีกครั้ง นอกจากนี้ยังหมายความว่าคุณไม่มีจุดล้มเหลวเพียงจุดเดียวในกรณีที่เซิร์ฟเวอร์ ClearCase ของคุณล่ม

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

ฉันคิดว่าความจริงที่ว่าทีมอื่น ๆ เริ่มใช้ Git ภายในเป็นสัญญาณที่มีความหมาย แต่ก็ยังไม่แข็งแกร่งพอเพราะมันสามารถถูกไล่ออกได้ตามความชอบส่วนตัว

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

ดังนั้นฉันจึงมีการประชุมสัปดาห์นี้กับ SVP ในการเปลี่ยนแปลงโครงสร้างพื้นฐานที่ต้องการให้ฉันอธิบายถึงข้อดีของ Git ให้เธอฟัง

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

สิ่งที่ฉันต้องการจริงๆคือสิ่งที่ทรงพลังพอที่จะผ่าน "กระบวนการนี้ได้ทำงานมา 20 ปีทำไมเราต้องเปลี่ยนมัน" ข้อโต้แย้ง.

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

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

• ความสามารถใหม่นี้จะนำมาซึ่งอะไร? มีบางอย่างที่เราไม่สามารถทำได้ในขณะนี้ที่เราต้องการจะทำและสิ่งใหม่นี้จะช่วยให้เรา? เริ่มจากบันทึกที่เป็นบวก

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

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

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

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

คุณอาจพบคำตอบนี้เพื่อโน้มน้าวใจ บริษัท ที่ฉันทำงานเพื่อใช้การควบคุมเวอร์ชัน เป็นประโยชน์