วิธีเพิ่มนักพัฒนาใหม่ให้กับทีม

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

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

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

นี่คือสถานการณ์:

• เรากำลังเข้าใกล้เกณฑ์ของกฎหมายของ Brooks - จุดที่เพิ่มนักพัฒนาใหม่จะเป็นการต่อต้าน
• แอปพลิเคชันค่อนข้างออกแบบมาอย่างดี แต่การใช้งานนั้นไม่เป็นระเบียบในบางจุด (โดยเฉพาะโค้ดที่เก่ากว่า)
• มีการทดสอบหน่วยสำหรับรหัสล่าสุดเท่านั้น เมื่อโครงการนี้เริ่มต้นเราไม่ได้ทำการทดสอบเป็นประจำ
• เอกสารและความคิดเห็นไม่สมบูรณ์
• แอปพลิเคชั่นมีทั้งขนาดใหญ่และซับซ้อน
• ลูกค้าเขียนรายละเอียดเกี่ยวกับโครงการของเขาเกือบทุกอย่างอย่างชัดเจนและ "เป็นมิตรกับโปรแกรมเมอร์"

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

แก้ไข:

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

สิ่งที่นักพัฒนาของเรา (ฉันเป็นหนึ่งในสองคน) ต้องทำคือ:

• กรอกใบสมัครที่มีอยู่ให้เสร็จ (ประมาณ 25% ของงานที่ต้องทำ)

• การสร้างโมดูลใหม่ที่จำเป็นสำหรับองค์กรของเหตุการณ์นี้ (ประมาณ 75% ของงานที่ต้องทำ) โมดูลใหม่นี้ไม่สามารถพัฒนาโดยไม่เข้าใจ API ของโปรแกรมหลัก

ฉันไม่สามารถประมาณการเวลาที่แน่นอน แต่เราอยู่ในสถานการณ์ที่มีความเสี่ยง

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

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

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

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

เป็นความคิดที่ดีที่จะเพิ่มคนตอนนี้หรือไม่?

ไม่หากเป็นไปได้ให้พยายามให้ลูกค้าเห็นด้วยกับการลดขอบเขตแทน

การเพิ่มบุคคลปลายนี้จะเพิ่มความเสี่ยงที่สำคัญและกำหนดเวลาไม่สามารถผลักดัน (เท่าที่ฉันเข้าใจ)

อย่าทำมัน

ยัง

มุมมองแบบดั้งเดิม

ในคำถามของคุณที่คุณอ้างถึงกฎหมายบรูกส์จากตำนาน Man-เดือน

การเพิ่มกำลังคนให้กับโครงการซอฟต์แวร์ล่าช้าทำให้ภายหลัง

หากต้องการเพิกเฉยกฎหมายของบรู๊คมีราคา อย่ามัลติทาสก์ มุ่งเน้นไปที่การส่งมอบผลิตภัณฑ์ที่ทำงานได้ขั้นต่ำ (MVP) จากนั้นมุ่งเน้นพลังงานของคุณในการสรรหาทรัพยากรการฝึกอบรมและการจัดการสมาชิกในทีมใหม่

สองเดือนนั้นสั้นมาก วางแผนการสรรหาพร้อมกับรายการที่เหนื่อยหน่ายและคุณจะเห็นว่าใช้เวลานานแค่ไหน

Larry Page และ Sergei Brin ใช้เวลาสองปีในการเลือกทีมเริ่มต้นสำหรับ Google การเลือกหมายเลขพนักงานคนที่สามของคุณก็ควรระมัดระวัง

Agile, New Millenium View

การแข่งขันผลักดันการทำงานเป็นทีมที่มีพลวัตมากกว่าตอนนี้ในยุคที่ Mythical Man-Month ถูกเขียนขึ้น (กลางปี ​​1960) อาชีพที่ยาวนานของ บริษัท หนึ่งได้หายไป ตอนนี้เราย้ายบ่อยระหว่างโครงการและ บริษัท การสร้างทีมที่รวดเร็วสร้างความสำเร็จ การเพิ่มความเร็วช้าเป็นปัจจัย จำกัด ที่รุนแรง ตัวอย่างที่ดีมาจากโครงการโอเพ่นซอร์ส startups และการเพิ่มการใช้งานของทีมในหลักสูตรวิทยาศาสตร์คอมพิวเตอร์

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

การผสานรวมด้านเทคนิคและสังคมของทีม Agile สำหรับพนักงานใหม่สามารถใช้:

• scrums ทุกวัน
• การเขียนโปรแกรมคู่
• refactoring
• เพิ่มการทดสอบหน่วยที่ขาดหายไป
• ขุนเอกสารแบบลีน
• ความคิดเห็นรหัส

ลูกแกะที่เสียสละ

ใน " รูปแบบองค์กรของการพัฒนาซอฟต์แวร์ Agile" James Coplien กล่าวถึงพลวัตของกลุ่มและค่าใช้จ่ายในการเพิ่มสมาชิกในทีมใหม่ รูปแบบของเขา "Sacrificial Lamb" มอบหมายการให้คำปรึกษาและการฝึกอบรมทั้งหมดให้กับบุคคลหนึ่งโดยดูแลส่วนที่เหลือของทีมจากการหยุดชะงัก

เป็นกลยุทธ์ที่คุณอาจต้องการพิจารณานำไปใช้

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

ปัจจุบันการให้คำปรึกษาทำได้โดยคนคนหนึ่งโดยเฉพาะในช่วงและหลังจากการต่อสู้ในตอนเช้าของเรา (8:30 น. ถึงประมาณ 9:15 น. รวมกัน) และในช่วงบ่ายระหว่าง 12 ถึง 3:30 น. (เขาทำงาน 7:00 - 3:30 น. PM)

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

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

หากคุณปฏิบัติตามกฎหมายของบรู๊คอย่างเคร่งครัดคุณอาจจะไม่เติบโตทีม

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

ในกรณีของคุณ? ฉันอยากจะแนะนำให้คนใหม่เขียนการทดสอบหน่วยที่หายไปทั้งหมด

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

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

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

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

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

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

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

คำแนะนำของฉัน:

นั่งลงกับลูกค้าของคุณอธิบายว่าคุณอยู่ในหัวของคุณและทำงานกับเขาเพื่อลดขอบเขตให้น้อยที่สุด

แก้ไขเพิ่งเห็นวันที่นี่ แล้วมันจะจบลงได้อย่างไร? (ขอบคุณ Ars Technica สำหรับการโพสต์คำถามสามเดือน;)

มีสองวิธีที่แตกต่างกันที่ฉันจะพิจารณาการตรวจสอบคือ:

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

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

วันที่ผ่านไปแล้ว แต่สำหรับใครก็ตามที่อ่านเรื่องนี้ในภายหลัง

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

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

หากพวกเขาไม่เต็มใจที่จะเจรจาขอบเขตลงคุณก็จะล้มเหลว

ไม่มีโอกาสที่จะส่งมอบโครงการนี้อย่างสมบูรณ์ภายในระยะเวลา หากคุณคิดว่าคุณเหลือ 25% ในโครงการที่ใช้เวลา 18 เดือนในการส่งมอบคุณจะเหลือเวลาอย่างน้อย 6 เดือน (จากนักพัฒนา ~ 2 คน) การเพิ่มบุคคลอื่นจะไม่เปลี่ยนแปลงสิ่งนี้อย่างมีนัยสำคัญ

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

ฉันหวังว่านี่จะได้ผลสำหรับคุณ