Büyük bir programlama ekibinde çalışmak nasıl bir şey?

Küçük bir programlama ekibinde çalıştığım için kendimi her zaman şanslı hissettim. En çok çalıştığım 11 programcı olduğunu düşünüyorum. Yüzlerce geliştirici ile bir proje üzerinde çalışmak nasıl bir şey? Binlerce? Ölçek nedir ve ne yapmaz?

EDIT: Tüm yanıtlar için teşekkürler! Çok az pozitif var gibi görünüyor:

• büyük mega kod tabanlarında çalışmak mümkün
• daha iyi iç kariyer gelişimi
• küfürlü yönetime karşı çalışan koruması (bu, küçük ve büyük + ve daha büyüktür)

Büyük ekiplerin başka bir yararı var mı?

Bürokrasi ölçeklerini çok iyi buluyorum.

Bunun dışında bir sürü değil. Büyük projelerin büyük ekipleri vardır, çünkü daha etkili (geliştirici başına) olduğu için başka bir yol yoktur. Karışıma verimsizlik (yani bilgi aktarımı ve iletişim) açısından ikinci bir kişi eklediğinizde maliyet ödersiniz.

Çalıştığım en büyük proje 5 farklı alanda 70 kadar geliştiriciye sahipti. Bir satırlık değişiklik bile minimum gün aldı, ancak bu, yapının Zürih'ten Londra'ya bir ağ bağlantısı üzerinden 45+ dakika sürmesi ve uygulamayı başlatmasının 45 dakika daha sürmesi nedeniyle oldu. Check-in'ler dosya başına yaklaşık 5 dakika sürdü. Şaka yapmıyorum. Londra geliştiricileri bunu kısa bir süre içinde yapabilirdi.

Her neyse, bulmaya eğilimli olduğunuz şey, büyük projelerde, bu kadar fazla etkileşimde bulunmadığınız bir grup ekip üyesine sahip olacağınızdır. Daha çok, gevşek bağlı bir mini proje koleksiyonu gibi. Bir keresinde Microsoft gelişiminin, projeleri Microsoft Office gibi büyük projeler için bile 5-7 geliştirici ekibine bölme eğiliminde olduğunu okudum.

Farkın bir kısmı da küçük ve büyük şirketler arasındaki farktır: daha büyük olanların daha fazla süreç, daha fazla kural, daha az esneklik vb. Ama bu kesinlikle garanti edilmez.

Yine de kariyer gelişimi için iyi olabilir. Küçük bir şirkette, bir promosyon almadan önce (veya şirket büyüyecek ve siz yukarıya doğru hareket edecek şekilde büyümelidir), daha büyük dev departmanlarında ekipler arasında hareket edebilirsiniz.

Ek olarak, bazen kendinizi bağlayacağınız ve onlardan öğrenebileceğiniz gerçekten akıllı insanlar bulabilirsiniz. Küçük şirketlerde bu kadar izole ve kendine güvenen bir programcılara biraz "garip", münzevi bir keşiş gibi yardımcı olabilir.

İletişim, ekibin büyüklüğü büyüdükçe bozulmaya başlayan en büyük şey olarak bulduğum şey. İletişimi sağlamak zorlaşıyor ve herkesin hala aynı sayfada olduğundan emin olmak zorlaşıyor. Yaklaşık 75 geliştiriciden oluşan bir ekipte dolaylı olarak çalışıyorum, ortak bir kod tabanı kullanıyoruz, ancak 75'in çoğu bireysel "etkinlikler" için daha küçük gruplara ayrılıyor. Bizim için iletişim sadece mutlak bir kabustur.

Daha büyük grupların yönetimi de daha zordur, çoğu ortamda 8-12 kişilik ek yönetim üyeleri dahil olduktan sonra, maalesef bu, iletişim altını tipik olarak bireysel alt kümelerin ve kendi gruplarının içinde bilgi tutmaya çalışın.

Silah sistemleri için yazılım ürettiğimde BÜYÜK yazılım geliştiricileri ekipleri vardı. Hiç kimse (bazıları sınıflandırılmış olan) gereksinimlerinin etrafına başını katamayacağından, hepsi takımlar ve takımların birbirleriyle nasıl etkileştikleri ile ilgiliydi.

1. Yapılandırma Yönetimi - gece inşa süreci - çok önemliydi. O günlerde dünyayı her gece yeniden derlemek için büyük bir dağıtılmış bilgi işlem kümesi gerekiyordu.

2. Çalışma izinleri - ve zamanınızı ana genel proje çizelgesinde doğru satır öğesine şarj etmek - boyunda büyük bir acıydı. 0.1 saate kadar. artışlarla.

Ancak en büyük anlaşma değişiklik bildirimi oldu. Özellikle arayüz değişiklikleri.

Bu çok önemliydi, bu çılgın iki katmanlı süreci icat ettiler. Çabaların çoğu, Arayüz Değişikliği Bildirim İsteği'nin (bildirimin kendisinin değil, bildirim isteğinin) bir veritabanı ve raporları ve neyi içermeyen ayrıntılı destek yazılımlarına sahip olduğundan emin olmaya başladı.

İstek onaylandıktan sonra, fiili bildirim aşağı yukarı söylenmeden geçti. Yani bu gerçekten tek katmanlı bir süreçti ve talep etkili bir şekilde bildirildi. Ancak şelale geliştirme yaparken, herhangi bir geliştirici ortaya çıkmadan önce her şey uzun bir süre düşünülmelidir.

Paralel çalışan çok sayıda insanla birlikte bir Yapılandırma Kontrol Kartı vardı. Çeşitli takım yöneticilerinin yanı sıra, işi basitçe değiştiren bir grup insan da değişiklikleri koordine etmekti.

İlk "gerçek" programlama işim, uluslararası hava trafik kontrol sistemlerini geliştirmek için başka bir ordu ile çalışmaktı. Bu çok başarılı bir girişimdi ve biz Yetenek Olgunluk Modeli Seviye 5 ortamı olarak kabul edildi. O zamandan beri orta ve küçük dükkanlarda bulundum. Peki, olması gereken en iyi yer hangisi? Şahsen ben her gün büyük bir küçük bir dükkan alırdım. Bazıları Seviye 5'i Kutsal Kâse olarak görse de, benim için boğuluyordu. Her şey belgelenmeli, onaylanmalı, imzalanmalı, vb. Beni yanlış anlamayın, özellikle hava trafik kontrolü kadar kritik sistemler için içindeki değeri kesinlikle görüyorum, ancak soru, gün? Bir şeyleri hayal edebilme ve sonra bunları uygulama özgürlüğü istiyor musunuz, veya gereksinimlere yazmak ister misiniz? Belki de ATC sistemi ile daha uzun süre kalsaydım, tasarım yapabilmenin yanı sıra geliştirebilme seviyesine yükselmiş olabilirdim, ancak gerekli X sayısı, Y onay sayısı, Z promosyon sayısı - hepsi iyi reçete edildi sapma şansı yok. Boğucuydu.

Son bir şey, genel olarak geliştiricilerin kalitesinin daha küçük şirketlerde gizlenebileceğinden çok daha yüksek olduğunu düşünüyorum. Çok büyük bir şirkette vasat olmak zor değil, ancak küçük bir şirkette acı verici bir şekilde belirginleşiyor ve genellikle uzun sürmüyor.

En az yüzlerce geliştiriciye sahip bir kuruluşta (kısaca) çalıştım. Ama elbette (?), Organizasyon dahili olarak bölünmüştür, böylece tek bir çalışan olarak diğerleriyle doğrudan temas kurmazsınız, bu da devam etmesi çok zor olur.

Belirli bir yerde, yazılım bileşenlere ayrıldı ve bileşenler etrafında ekipler kuruldu. Bazı takımlar yalnızca tek bir (büyük) bileşenle çalışırken, birçok takım bir grup (daha küçük) bileşenden sorumluydu.

Tabii ki bu çok büyük bir kod tabanı ile çalışmanın yaptığı her şeyi ifade eder; Konfigürasyon yönetimi, bina, entegrasyon ve benzeri şeyler önemli, büyük hale gelir ve bunlar da özel olarak ayrılmış departmanlar tarafından yapılır. Ve tüm geliştirici departmanlarının çıktılarını toplayabilmeniz ve düzenli olarak (çalıştığım haftada bir kez) hepsini gerçekten çalışan tek bir bütün haline entegre ettiğiniz için onları korkutuyorsunuz.

Büyük bir programcı ekibi için hiç çalışmadım , ancak boyutu artan bir kuruluşun sonucu genellikle daha fazla kural. Bu her zaman kötü bir şey olmak zorunda değildir! Herkesin hayatını zorlaştıran kurallara ek olarak, çalışanları korumak ve iyi bir süreç sağlamak için daha fazla kural vardır.

Küçük kuruluşlardaki yöneticilerin, bir işletme İK departmanı tarafından derhal feshedilecek şeylerden kaçtığını gördüm.

Büyük projelerle fark ettiğim tek fark ofis politikaları. Projeler ne kadar büyük olursa siyaset o kadar baskındır.

Okul dışı ilk projem birkaç yüz geliştiriciydi. Okuldan taze bir kendini beğenmiş ve naieve geliştirici olarak ben gerçekten bunun için hazır değildi . (Ve tek şey benim hiney kaydedilen tek şey şimdiye kadar gerçekten sizi korumak) yaptığım arkadaşlar miktarı oldu.

Bundan öğrendiğim en büyük ders bu. Herkesle arkadaşlık kurmaya çalışın . Gerizekalılar bile. Özellikle, bir dakika boyunca çalışmayı durdurma ve daha önce hiç konuşmadığınız biriyle konuşma şansınız varsa, yapın.

Bir zamanlar 500'den fazla çalışanı olan bir ekip üzerinde çalıştım, bunların yaklaşık 200'ü geliştiriciydi. Birkaç farklı SOA çözümünü entegre eden bir EOA sunuyorduk.

Uygulamada, her biri toplam teslim edilebilirliğin farklı bir yönünden sorumlu olan, her biri değişen sayıda programcıya (ekibimizde 3) sahip 30 ila 50 takım arasında bir yer vardı.

Şimdiye kadar çalıştığım en büyük ekip yaklaşık 15 kişiydi (bu, farklı bir şirkette sadece 3 veya 4 aydı). Takımda teknik liderdim ve sabah 7'de çalışmaya başladım, herkes girmeden 2 saat önce alırdım, kendi görevlerimi yapabilmemin tek yolu buydu.

8 veya 10'dan fazla geliştiriciye sahip bir ekip üzerinde çalışmak istemiyorum, 15 tek bir ekip için çok fazlaydı (ekip maalesef çağrım yerine kolayca ikiye bölünebilir), 3 veya 4 devs bir güzel rahat boyutu IMHO