ฉันต้องการลูกนี้ในเดือนเดียว - ส่งผู้หญิงเก้าคน!

ภายใต้สถานการณ์ใด (ถ้ามี) - การเพิ่มโปรแกรมเมอร์ลงในทีมจริงจะช่วยเร่งการพัฒนาโครงการล่าช้าหรือไม่?

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

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

มีหลายสิ่งที่ฉันคิดว่าจำเป็นแต่ไม่เพียงพอสำหรับสิ่งนี้ที่จะเกิดขึ้น (ไม่มีคำสั่งพิเศษ):

• บุคคลที่เสนอที่จะเพิ่มในโครงการต้องมี:
  • อย่างน้อยความเข้าใจที่สมเหตุสมผลของโดเมนปัญหาของโครงการ
  • มีความเชี่ยวชาญในภาษาของโครงการและเทคโนโลยีเฉพาะที่พวกเขาจะใช้สำหรับงานที่พวกเขาจะได้รับ
  • ความสามารถของพวกเขาจะต้อง / ไม่ / มากหรือน้อยกว่าสมาชิกที่อ่อนแอที่สุดหรือแข็งแกร่งที่สุดตามลำดับ สมาชิกที่อ่อนแอจะระบายพนักงานที่มีอยู่ของคุณด้วยปัญหาระดับอุดมศึกษาในขณะที่คนใหม่ที่แข็งแกร่งเกินไปจะรบกวนทีมด้วยทุกสิ่งที่พวกเขาได้ทำและกำลังทำผิด
  • มีทักษะการสื่อสารที่ดี
  • มีแรงจูงใจสูง (เช่นสามารถทำงานอย่างอิสระโดยไม่ต้องมีการผลิต)
• สมาชิกในทีมที่มีอยู่ต้องมี:
  • ทักษะการสื่อสารที่ยอดเยี่ยม
  • ทักษะการจัดการเวลาที่ยอดเยี่ยม
• หัวหน้าโครงการ / การจัดการต้องมี:
  • จัดลำดับความสำคัญที่ดีและมีความสามารถในการจัดสรรทรัพยากร
  • การเคารพในระดับสูงจากสมาชิกในทีมที่มีอยู่
  • ทักษะการสื่อสารที่ยอดเยี่ยม
• โครงการจะต้องมี:
  • ข้อกำหนดการออกแบบซอฟต์แวร์ที่ดีสมบูรณ์และจัดทำเป็นเอกสาร
  • เอกสารที่ดีของสิ่งต่าง ๆ ที่นำไปใช้แล้ว
  • การออกแบบแบบแยกส่วนเพื่อให้แยกชิ้นส่วนความรับผิดชอบชัดเจนออก
  • กระบวนการอัตโนมัติที่เพียงพอสำหรับการประกันคุณภาพสำหรับระดับข้อบกพร่องที่ต้องการซึ่งอาจรวมถึง: การทดสอบหน่วยการทดสอบการถดถอยการปรับใช้การสร้างอัตโนมัติเป็นต้น)
  • ระบบติดตามบั๊ก / คุณสมบัติที่ขณะนี้อยู่ในสถานที่และในการใช้งานโดยทีม (เช่น trac, SourceForge, FogBugz, ฯลฯ )

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

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

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

• มาสายก่อนที่คุณจะเริ่มต้น (มากกว่าเวลา) และ / หรือ
• ลดลง 1 ชม. 1 เวลา

หวังว่าจะช่วย!

มันจะช่วยถ้าคุณมีโครงการที่ขับเคลื่อนด้วยทรัพยากร

ตัวอย่างเช่นพิจารณาสิ่งนี้:

คุณต้องทาสีโปสเตอร์ขนาดใหญ่พูดขนาด 4 x 6 เมตร โปสเตอร์ที่มีขนาดใหญ่คุณอาจใส่คนสองหรือสามคนไว้ข้างหน้าและวาดภาพคู่ขนาน อย่างไรก็ตามการวางตำแหน่ง 20 คนไว้ข้างหน้ามันจะไม่ทำงาน นอกจากนี้คุณจะต้องการคนที่มีทักษะเว้นแต่คุณต้องการโปสเตอร์เส็งเคร็ง

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

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

น่าเศร้าที่มีโครงการไม่มากนักในโลกของเราซึ่งเป็นเหตุผลว่าทำไม docgnome ถึงเคล็ดลับเกี่ยวกับหนังสือ Mythical Man-Month จึงเป็นคำแนะนำที่ดีมาก

อาจเป็นไปตามเงื่อนไขต่อไปนี้:

1. โปรแกรมเมอร์คนใหม่เข้าใจโครงการนี้แล้วและไม่ต้องการเวลาเพิ่ม
2. โปรแกรมเมอร์ใหม่มีความเชี่ยวชาญในสภาพแวดล้อมการพัฒนาอยู่แล้ว
3. ไม่จำเป็นต้องใช้เวลาในการดูแลเพื่อเพิ่มนักพัฒนาให้กับทีม
4. แทบไม่จำเป็นต้องมีการสื่อสารระหว่างสมาชิกในทีม

ฉันจะแจ้งให้คุณทราบครั้งแรกที่ฉันเห็นสิ่งเหล่านี้ทั้งหมดในครั้งเดียว

ตาม Mythical Man-Month เหตุผลหลักที่ทำให้ผู้คนเพิ่มเข้ามาในโปรเจ็กต์ล่าช้าทำให้ในภายหลังคือ O (n ^ 2) ค่าใช้จ่ายในการสื่อสาร

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

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

หากโปรแกรมเมอร์ที่มีอยู่ไม่มีความสามารถโดยสิ้นเชิงการเพิ่มโปรแกรมเมอร์ที่มีความสามารถอาจช่วยได้

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

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

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

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

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

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

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

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

3) สมาชิกในทีมอื่น ๆ มีความอดทนมาก

ฉันคิดว่าคนที่เพิ่มเข้าไปในตอนท้ายของการทำงานสามารถเร่งทำสิ่งต่าง ๆ ได้ถ้า:

1. สามารถทำงานแบบขนาน

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

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

ระวังผู้จัดการที่ธนาคารในงานประเภทนี้ที่จะแจก มันฟังดูดี แต่ในความเป็นจริงมันมักจะไม่เพียงพอที่จะตัดเวลาสำคัญออกจากโครงการ

• โมดูลในตัวที่ยังไม่ได้เริ่ม
• ไม่มีเครื่องมือในการพัฒนาที่สามารถบูรณาการได้ (เช่นผู้จัดการสร้างอัตโนมัติ)

ในขั้นต้นฉันกำลังคิดถึงสิ่งต่าง ๆ ที่ให้พวกเขาหลีกเลี่ยงวิถีการพัฒนาของผู้คนในปัจจุบัน ฉันเห็นด้วยกับ Mythical Man-Month แต่ฉันก็คิดว่ามีข้อยกเว้นทุกอย่าง

ฉันคิดว่าการเพิ่มคนในทีมอาจทำให้โครงการเร็วขึ้นกว่าการเพิ่มพวกเขาในโครงการ

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

แน่นอนว่าคุณได้ว่าจ้างนักพัฒนาที่มีความสามารถและมีแรงจูงใจซึ่งสามารถสืบทอดโครงการขนาดใหญ่และเรียนรู้อย่างอิสระ :-)

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

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

1. ทรัพยากรดีแค่ไหนในการยกมันขึ้นมา นักพัฒนาที่ดีที่สุดสามารถเดินไปยังไซต์ใหม่และแก้ไขข้อบกพร่องได้อย่างมีประสิทธิภาพด้วยความช่วยเหลือเล็กน้อย ทักษะนี้หายาก แต่สามารถเรียนรู้ได้
2. ความสามารถในการแบ่งแยกของงาน พวกเขาต้องสามารถทำงานกับวัตถุและฟังก์ชั่นได้โดยไม่ต้องสะดุดกับผู้พัฒนาที่มีอยู่และทำให้พวกเขาช้าลง
3. ความซับซ้อนของโครงการและเอกสารประกอบ หากเป็นแอปพลิเคชั่น ASP.Net แนวปฏิบัติที่ดีที่สุดของวานิลลาและสถานการณ์ทางธุรกิจทั่วไปที่มีเอกสารที่ดีแล้วนักพัฒนาที่ดีก็สามารถติดอยู่ได้ทันที ปัจจัยนี้จะเป็นตัวกำหนดว่าจะใช้เวลาเท่าใดทรัพยากรที่มีอยู่จะต้องลงทุนในการสอนและดังนั้นผลกระทบเชิงลบเริ่มต้นของทรัพยากรใหม่
4. ระยะเวลาที่เหลือ สิ่งนี้มักถูกประเมินผิด ๆ เช่นกัน บ่อยครั้งที่ตรรกะจะเป็นเราเหลือเพียง x สัปดาห์และจะใช้เวลา x + 1 สัปดาห์ในการเพิ่มความเร็วให้กับใครสักคน ในความเป็นจริงโครงการกำลังจะล้มลงและในความเป็นจริงมีเวลาเหลืออีก 2 สัปดาห์เพื่อพัฒนาและได้รับทรัพยากรมากขึ้นในไม่ช้าแทนที่จะช่วยให้ในภายหลัง

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

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

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

การเพิ่มนักพัฒนานั้นสมเหตุสมผลเมื่อผลผลิตที่นักพัฒนาเพิ่มเติมได้รับนั้นเกินกว่าประสิทธิภาพที่สูญเสียไปสำหรับการฝึกอบรมและการจัดการนักพัฒนาเหล่านั้น