เหตุใดการเพิ่มบุคคลเพิ่มเติมในโปรเจ็กต์ล่าช้าจึงทำได้ในภายหลัง

มันเป็นภาษิตที่ใช้กันทั่วไปว่าการเพิ่มโปรแกรมเมอร์มากขึ้นไปยังโปรเจ็กต์ล่าช้าจะทำให้เรื่องแย่ลง ทำไมนี้

บทนำค่าใช้จ่าย

ผู้พัฒนาใหม่แต่ละคนจะต้องได้รับการแนะนำให้รู้จักกับฐานของรหัสและกระบวนการพัฒนาซึ่งไม่เพียง แต่ใช้เวลาของคนใหม่เท่านั้น แต่ยังต้องการความช่วยเหลือจาก [a] นักพัฒนาอาวุโส [ แนะนำ ] ด้วย(แนะนำพวกเขาผ่านกระบวนการสร้างอธิบายกระบวนการทดสอบ มีข้อผิดพลาดในฐานรหัสที่มีรายละเอียดมากขึ้นตรวจสอบรหัส ฯลฯ )

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

นอกจากคำตอบอื่น ๆ : ปัจจัยที่ต้องพิจารณาอีกประการหนึ่งคือการสื่อสาร

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

ปัญหาที่อ้างถึงในหนังสือที่ประกาศใช้กฎหมายฉบับนี้ว่าThe Mythical Man-Monthนั้นเป็นการสื่อสาร เขาเริ่มต้นด้วยการพูดว่า:

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

เขาพูดถึงการฝึกอบรมเป็นส่วนหนึ่งของปัญหา:

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

... แต่ตั้งข้อสังเกตว่าการสื่อสารถึงกันเป็นปัจจัยที่ใหญ่กว่า :

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

นอกจากนี้ยังเป็นที่น่าสังเกตว่า Fred Brooks (ผู้แต่ง) มีภูมิหลังที่จะรู้ว่าเขากำลังพูดถึงอะไร หนังสือส่วนใหญ่อ้างอิงจากประสบการณ์ของเขาในการจัดการโครงการ OS / 360 ของ IBM แม้จะมีสมัครพรรคพวกหลายสิบปีที่ประกาศวิธีการจัดการ "ที่ดีขึ้น" และบางคนถึงกับใช้ชื่อเจ๋ง ๆ (eXtreme, Agile, Scrum และอื่น ๆ ) เมื่อคุณพูดถึงมันสิ่งสำคัญเล็ก ๆ น้อย ๆ¹ดูเหมือนจะเปลี่ยนไป

¹สำหรับคำนิยามของ "สาระสำคัญ" ให้ดูที่ผู้เขียนเดียวกัน "ไม่มีกระสุนเงิน: เอสเซ้นและอุบัติเหตุในสาขาวิชาวิศวกรรมซอฟแวร์" รวมอยู่ใน 20 ^THฉบับครบรอบของกับ myth Man

มันไม่ได้เป็นเพียงภาษิต; มันตรวจสอบได้ ตรวจสอบบรูคส์กับ myth Man

นี่คือความคิดบางอย่างเกี่ยวกับปัญหานี้ ...

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

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

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

เพื่อทำให้มันง่ายขึ้นลองนึกภาพโครงการชายเดี่ยวที่ค่อนข้างง่ายซึ่งมีกำหนดจะไปเป็นเวลา 1 สัปดาห์: ในวันพฤหัสบดีคุณรู้ว่ามันจะไม่เสร็จตามกำหนดเวลาซึ่งจะใช้เวลาโปรแกรมเมอร์หนึ่งคนเช่น 6-7 วันแทน จาก 5 หากคุณเพิ่มโปรแกรมเมอร์อีกคน ณ จุดนั้นพวกเขาจะต้องทำงานกับโปรแกรมเมอร์ 1 เป็นเวลาอย่างน้อยสองสามชั่วโมงหรือหนึ่งวันหรือมากกว่านั้นถามคำถามมากมายเพื่อเร่งความเร็ว ฯลฯ คุณอาจจะไม่ได้รับ ผลผลิตบวกใด ๆ สุทธิในช่วงที่เหลือของสัปดาห์ โปรแกรมเมอร์คนใหม่มีแนวโน้มที่จะแนะนำบั๊กพิเศษบางอย่างด้วยเช่นกัน (เนื่องจากพวกเขาไม่รู้โค้ดที่มีอยู่รวมทั้งโปรแกรมเมอร์ 1) ดังนั้นมันจะทำให้วงจรการใช้งานและการทดสอบสิ้นสุดลงในอีกหนึ่งหรือสองวัน โครงการจะใช้เวลาสองสัปดาห์เต็มในการทำงานแทนที่จะเป็นโครงการดั้งเดิม!

Fred Brooks เขียนหนังสือทั้งเล่ม "The Mythical Man-Month" ตอบคำถามนี้

นี่คือเวอร์ชั่นฉบับย่อที่สกปรก:

1) มีข้อ จำกัด ว่าคุณสามารถแบ่งโปรเจ็กต์ออกเป็นชิ้น ๆ เพื่อกำหนดให้โปรแกรมเมอร์มากขึ้นได้อย่างไร

2) การแบ่งโครงการออกเป็นหลาย ๆ คนเพิ่มจำนวนการสื่อสารที่จำเป็นในการประสานงานทุกส่วนของแอป การสื่อสารมากขึ้น = การทำงานมากขึ้น

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

4) มี "J-Curve" เมื่อคุณเพิ่มสมาชิกแต่ละคนในทีม นั่นคือทรัพยากรการผลิตที่มีอยู่ต้องใช้เวลาในการทำให้ผู้คนใหม่ ๆ ได้เร็วขึ้นอย่างที่พวกเขาอาจใช้เวลาทำงานในโครงการ ในที่สุดคุณอาจเพิ่มกำลังการผลิต แต่มันทำให้โครงการช้าลงชั่วคราว ต่อมาในโครงการยิ่งต้องเรียนรู้มากเท่าใด

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

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

ภาษิตที่ใช้ได้กับฉันเสมอคือคุณไม่สามารถทำให้ผู้หญิงเก้าคนสร้างลูกได้ในหนึ่งเดือน

ฉันยังแนะนำ "Peopleware" โดย DeMarco และ Lister

และ "The Deadline" โดย DeMarco นำเสนอสิ่งนี้และจำนวนของซอฟต์แวร์การจัดการโครงการโรคและการเข้าใจผิดอื่น ๆ ในรูปแบบที่เบาสบายและอ่านง่ายมาก

นอกจากนี้ยังนำเสนอพลวัตของผู้คนที่ทำงานในโครงการ / ทีมและมีรายละเอียดเกี่ยวกับสิ่งต่างๆเช่นการสื่อสารและการแนะนำทำให้เสียเวลาในการทำงานของทีม

หนังสือเหล่านี้ค่อนข้างถูกฉันขอแนะนำให้คุณรับพวกเขา (Amazon หรือ The Book Depository มีพวกเขา) และได้อ่าน คำตอบสั้น ๆ ที่นี่ไม่สามารถสร้างความยุติธรรมกับคำถามที่ถาม

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

หากคุณกำลังจัดการทีมงานของนักพัฒนาคุณควรมีผู้ติดต่อหลายคนในขณะนี้ของคนที่คุณต้องการจ้างถ้าคุณมี openning เข้าร่วมกลุ่มนักพัฒนา

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

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

กำหนดการโครงการใด ๆ ถึงวันที่?

ประหยัดได้ในวันที่ฝนตกเพราะเมื่อโปรเจ็กต์หล่นลงมามันก็เหมือนพายุเฮอริเคน

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

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

ฉันอยากจะชี้ให้เห็นบางสิ่งบางอย่างที่ไม่สนใจทั้งหมดโดยคำตอบอื่น ๆ

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

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

เห็นได้ชัดว่าผู้คนข้างบนสูญเสียศรัทธาในตัวคุณ พวกเขาเรียกร้องให้เด็กชายตัวใหญ่ทำสิ่งที่คุณทำ

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

ใช้เวลาของคุณ :-)