อะไรคือวิธีที่จะบรรเทาผลกระทบของ Mythical Man Month?

กฎหมายของ Brooks: การ เพิ่มกำลังคนไปยังโครงการซอฟต์แวร์ที่ล่าช้าทำให้ภายหลัง

ในหนังสือของเขาNo Silver Bullet - Essence and Accidents of Software Engineeringเฟรดเดอริกบรูกส์กำหนดแนวคิดของMythical Man Month :

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

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

MMM คืออะไร

ก่อนอื่นฉันต้องการอธิบายบริบทของกฎหมายของบรูค อะไรคือสมมติฐานที่ทำให้เขาสร้างมันขึ้นมาใหม่ในปี 1975?

Man-month เป็นหน่วยงานสมมุติที่แสดงถึงงานที่ทำโดยหนึ่งคนในหนึ่งเดือน กฎหมายของ Brooks บอกว่าเป็นไปไม่ได้ที่จะวัดงานที่มีประโยชน์ในช่วงหลายเดือน

^{แหล่งที่มา: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

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

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

แต่มันต้องเป็นอย่างนี้จริงเหรอ? เราจะต้องมีการเขียนสาและให้ช่องทางการสื่อสารเพื่อn(n − 1) / 2ที่nคือจำนวนของนักพัฒนาหรือไม่

เรารู้ว่ามี บริษัท ที่ผู้พัฒนาหลายพันรายทำงานในโครงการขนาดใหญ่ ... และมันใช้งานได้ ดังนั้นจะต้องมีสิ่งที่เปลี่ยนไปตั้งแต่ปี 1975

ความเป็นไปได้ที่จะบรรเทา MMM

ในปี 2015 PuppetLabs และไอทีปฏิวัติตีพิมพ์ผลของ2015 รัฐ DevOps รายงาน ในรายงานดังกล่าวพวกเขาเพ่งความสนใจไปที่ความแตกต่างระหว่างองค์กรที่มีประสิทธิภาพสูงและองค์กรที่ไม่ได้ผลงานสูง

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

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

นี่คือกราฟจากรายงานนั้น -

ในขณะที่องค์กรที่มีประสิทธิภาพต่ำสอดคล้องกับข้อสันนิษฐานในตำนานมนุษย์เดือน องค์กรที่มีประสิทธิภาพสูงสามารถปรับจำนวนการใช้งาน / วัน / dev เชิงเส้นด้วยจำนวนนักพัฒนา

การนำเสนอที่ยอดเยี่ยมที่DevOpsDays London 2016โดย Gene Kim พูดถึงการค้นพบนี้

ทำอย่างไร

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

• ดีถึงดีมาก: ทำไมบาง บริษัท ถึงทำกระโจน ... และคนอื่นไม่ทำโดย Jim Collins
• ขอบความเร็วสูง: ผู้นำตลาดใช้ประโยชน์จากความเป็นเลิศในการดำเนินงานเพื่อเอาชนะการแข่งขันโดยสตีเวนสเปียร์ได้อย่างไร
• เศรษฐศาสตร์ใหม่สำหรับอุตสาหกรรมรัฐบาลการศึกษาโดย W. Edwards Deming

สำหรับซอฟต์แวร์และไอทีองค์กรหนึ่งในปัจจัยที่สำคัญสำหรับการเป็นองค์กรที่มีประสิทธิภาพสูงคือการมุ่งเน้นคุณภาพและความเร็ว

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

ไม่มีเวลาเพียงพอและหนี้สินทางเทคนิคก็ยิ่งแย่ลงเรื่อย ๆ

อะไรคือสิ่งที่ทำให้หนี้สินทางเทคนิคเติบโต

• รหัสดั้งเดิม
• การกำหนดค่าสภาพแวดล้อมด้วยตนเอง
• การทดสอบด้วยตนเอง
• การปรับใช้ด้วยตนเอง

รหัสเดิมตามที่กำหนดไว้ในการทำงานอย่างมีประสิทธิภาพด้วยรหัสเดิมโดย Michael Feathers เป็นรหัสใด ๆ ที่ไม่มีการทดสอบอัตโนมัติ

ทางลัดเวลาใดก็ได้ที่ใช้ในการรับรหัสเพื่อการผลิต; การดำเนินงานเป็นภาระกับการบำรุงรักษาของหนี้นี้ตลอดไป จากนั้นกระบวนการปรับใช้จะนานขึ้นเรื่อย ๆ

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

หนึ่งในหลักคำสอนของ DevOps คือความน่าเชื่อถือมาจากการปรับใช้ขนาดเล็กให้บ่อยขึ้น

ตัวอย่าง

• Jon Jenkins ที่ Velocity 2011 : Amazon กำลังทำ15k deploys / วัน
• Ken Exner ที่งาน AWS Summit 2015 : Amazon กำลังทำเงินได้ถึง 136k ต่อวัน

งานนำเสนอทั้งสองนี้แสดงทุกสิ่งที่ Amazon ทำเพื่อลดเวลาที่ใช้ในการปรับใช้รหัสเพื่อการผลิต

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

ซึ่งหมายความว่าภายใต้เงื่อนไขบางประการด้วยสถาปัตยกรรมที่เหมาะสมการปฏิบัติทางเทคนิคที่ถูกต้องบรรทัดฐานทางวัฒนธรรมที่ถูกต้องประสิทธิภาพการทำงานของนักพัฒนาสามารถขยายได้เมื่อจำนวนนักพัฒนาเพิ่มขึ้น และ DevOps อยู่ตรงกลางของทั้งหมดนี้

สิ่งที่ฉันทำ (และนี่เป็นเพียงความคิดเท่านั้น) มีดังนี้:

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

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

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

การพูดโดยเฉพาะจากมุมมองของ CI การเพิ่มจำนวนของนักพัฒนาที่ทำงานในโครงการมักจะแปลเป็นคนมากขึ้นที่ทำงานในสาขาเดียวกัน

ระบบ CI แบบดั้งเดิมมีปัญหาเรื่องความสามารถในการปรับขนาดในส่วนนี้ความน่าจะเป็นของการแตก / การถดถอย / การอุดตันจะเพิ่มความเร็วในการรวมที่ช้าลงและเชิญทีมเล็ก ๆ ให้แยกตัวออกจากกัน ดูขนาดการรวมระบบอย่างต่อเนื่องสำหรับโครงการ / ทีมขนาดใหญ่ได้อย่างไร . สิ่งนี้เล่นได้ตามแนวคิด Mythical Man Month

ทางออกที่ฉันแนะนำในคำตอบสำหรับคำถามนั้นระบบ CI ที่ปรับขนาดได้สูงจะช่วยให้สามารถโยกย้ายไปสู่ ​​CI จริง - การรวมสาขา / ลำตัวตามลำต้นเดียวสำหรับทีมที่ยิ่งใหญ่กว่าทั้งหมด (แม้จะมีขนาดใหญ่)

ทุกคนในหน้าเดียวกันการใช้เครื่องมือ / กระบวนการอัตโนมัติแบบเดียวกันและการตรวจสอบ QA อัตโนมัติส่วนใหญ่ภายในระบบ CI ทำให้การเปลี่ยนบทบาทและโฟกัสระหว่างสมาชิกในทีมง่ายขึ้น กระบวนการพัฒนาทั้งหมดจะราบรื่นขึ้นคาดเดาได้มากขึ้นและผ่อนคลายมากขึ้น

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

ฉันเชื่อว่าสิ่งเหล่านี้สามารถมองเห็นได้ในฐานะที่เป็นเอฟเฟกต์แนวคิด Mythical Man Month