มีความสัมพันธ์จริง ๆ ระหว่างจำนวนคนที่มอบหมายให้โครงการและจำนวนข้อบกพร่องหรือไม่?

นี่คือใบเสนอราคาจากคู่มือการฝึกอบรมที่ทำงานเกี่ยวกับ SLIM และการประเมินซอฟต์แวร์:

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

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

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

ฉันไม่สามารถค้นหาเอกสารใด ๆ นอกเหนือจากเอกสารเกี่ยวกับแบบจำลองพัทนัม (ซึ่งใช้โดย SLIM) ที่แนะนำความสัมพันธ์แบบใดก็ได้ที่รู้จักระหว่างข้อบกพร่องกับความพยายามหรือข้อบกพร่องและจำนวนคนในโครงการ นี่เป็นความสัมพันธ์ที่รู้จักกันดีและเป็นการยืนยันว่า "มีคนมากกว่า = ข้อบกพร่องมากขึ้น" ถูกต้องหรือไม่?

สัญชาตญาณของฉันเป็นเช่นนี้:

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

และ

นักพัฒนาที่ดีนั้นหายากจึงหาและจ้างได้ยากกว่าคนทั่วไป
=> ยิ่งคนที่ได้รับมอบหมายในโครงการขนาดที่กำหนดมากเท่าไหร่ระดับความสามารถเฉลี่ยของพวกเขาที่ต่ำกว่า
=> ยิ่งจำนวนของข้อบกพร่องที่เกิดขึ้นสูงขึ้น

แต่สิ่งเหล่านี้อาจเป็นเพียงเหตุผลของฉันฉันไม่มีหลักฐานสนับสนุน

ในฐานะที่เป็นหมายเหตุด้านสมมติฐานของคุณเน้นด้านล่างเป็น IMHO (เศร้า) ค่อนข้างแข็งแกร่งโดยคำนึงถึงสถานะของอาชีพของเรา:

นี้ดูเหมือนว่า counterintuitive, สมมติว่าเป็นกระบวนการที่ดีและวิศวกรที่มีความสามารถ [ ... ] สัญชาตญาณของฉันแสดงให้เห็นว่ามีความสัมพันธ์ระหว่างความพยายามและข้อบกพร่องในโครงการที่ใช้เทคนิคที่มีคุณภาพที่เหมาะสม

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

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

ดังนั้นสิ่งที่เกิดขึ้นจริงคือโครงการขนาดใหญ่มีข้อบกพร่องมากกว่าซึ่งไม่น่าแปลกใจเลย

ดูเหมือนว่าจะเป็นเรื่องที่เข้าใจง่ายโดยถือว่าเป็นกระบวนการที่ดีและวิศวกรที่มีความสามารถ

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

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

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

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

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

ลองแยกการยืนยันเกี่ยวกับจำนวนคนสักครู่

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

ดังนั้นหากคุณสมมติว่าความพยายามมากขึ้นที่ใส่เข้าไปในโครงการยิ่งมีการเขียนโค้ดมากขึ้นคุณอาจใช้ความพยายามเป็นพร็อกซีเพื่อกำหนดขนาดเพื่อทำนายจำนวนของข้อบกพร่อง ความสัมพันธ์ระหว่างขนาด (เช่น LOC) และจำนวนข้อบกพร่องได้รับการแสดงครั้งแล้วครั้งเล่าในการทำงานโดย Watts Humphrey, Capers Jones และอื่น ๆ

ฉันไม่เห็นว่าจำนวนคนเข้ากันได้ดีแค่ไหน

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

ฉันสมมติว่าสิ่งนี้ จำกัด เฉพาะสมาชิกของทีมหลักในการเขียนโปรแกรมและไม่ใช่สถานการณ์ที่มีผู้เชี่ยวชาญเช่น: UI, UX, DBA เป็นต้น

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

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

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

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