การทำงานในทีมการเขียนโปรแกรมขนาดใหญ่เป็นอย่างไร

ฉันรู้สึกโชคดีที่ได้ทำงานเป็นทีมเล็ก ๆ ฉันคิดว่าสิ่งที่ฉันทำงานด้วยมากที่สุดคือโปรแกรมเมอร์ 11 คน การทำงานกับโครงการที่มีนักพัฒนาหลายร้อยคนเป็นอย่างไร พัน? ขนาดและสิ่งที่ไม่อะไร

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

• เป็นไปได้ที่จะทำงานบนรหัสฐานขนาดใหญ่
• การพัฒนาอาชีพภายในที่ดีขึ้น
• การคุ้มครองพนักงานจากการจัดการที่ไม่เหมาะสม

มีประโยชน์อื่นใดอีกหรือไม่สำหรับทีมใหญ่?

ฉันพบว่าระบบราชการมีขนาดที่ดีมาก

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

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

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

ส่วนหนึ่งของความแตกต่างคือความแตกต่างระหว่าง บริษัท ขนาดเล็กและขนาดใหญ่: บริษัท ขนาดใหญ่มักจะมีกระบวนการมากขึ้นกฎระเบียบมากขึ้นความยืดหยุ่นน้อยลงและอื่น ๆ แต่นั่นไม่ได้รับประกันว่าจะได้ผล

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

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

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

การจัดการกลุ่มขนาดใหญ่ก็ยากขึ้นเช่นกันในสภาพแวดล้อมส่วนใหญ่หลังจาก 8-12 คนสมาชิกเพิ่มเติมของการจัดการมีส่วนร่วมเศร้านี้เพียงแค่พูดเกินจริงปัญหาการสื่อสารที่มันมักจะสร้างสภาพแวดล้อมประเภท "ไซโล" ที่ส่วนย่อยแต่ละเริ่มแตกออก กลุ่มใหญ่และพยายามเก็บความรู้ไว้ในกลุ่ม

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

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

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

แต่ข้อตกลงที่ใหญ่ที่สุดคือการแจ้งเตือนการเปลี่ยนแปลง การเปลี่ยนแปลงส่วนต่อประสานโดยเฉพาะอย่างยิ่ง

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

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

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

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

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

ฉันทำงาน (สั้น ๆ ) ในองค์กรที่มีนักพัฒนาอย่างน้อยหลายร้อยคน แต่แน่นอน (?) องค์กรมีการแบ่งพาร์ติชันภายในเพื่อให้คุณในฐานะพนักงานคนเดียวไม่ได้ติดต่อโดยตรงกับคนอื่นทั้งหมดซึ่งจะยากมากที่จะติดตาม

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

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

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

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

ข้อแตกต่างอย่างหนึ่งที่ฉันสังเกตเห็นจากโครงการขนาดใหญ่คือการเมืองในสำนักงาน ยิ่งโครงการยิ่งใหญ่ทางการเมืองก็ยิ่งมากเท่านั้น

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

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

ฉันเคยใช้เวลาหนึ่งปีทำงานกับทีมที่มีมากกว่า 500 คนในนั้นประมาณ 200 คนเป็นนักพัฒนา เราส่งมอบ EOA โดยรวมโซลูชัน SOA ที่แตกต่างหลากหลาย

ในทางปฏิบัติมีอยู่ระหว่าง 30 ถึง 50 ทีมแต่ละทีมมีจำนวนโปรแกรมเมอร์ที่แตกต่างกัน (3 คนในทีมของเรา) แต่ละคนมีหน้าที่รับผิดชอบในด้านต่าง ๆ ของการส่งมอบโดยรวม

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

ฉันไม่ต้องการทำงานกับทีมที่มีนักพัฒนามากกว่า 8 หรือ 10 คน 15 คนนั้นมากเกินไปสำหรับทีมเดียว (ทีมสามารถแบ่งออกเป็นสองทีมได้อย่างง่ายดายไม่ใช่การโทรของฉัน) 3 หรือ 4 devs เป็น ขนาดที่ดีสะดวกสบาย IMHO