Bu bebeğe bir ay içinde ihtiyacım var - bana dokuz kadın gönder!

Hangi koşullar altında - eğer varsa - bir ekibe programcı eklemek zaten geç bir projenin gelişimini hızlandırır mı?

Kesin koşullar, projenize çok açıktır (örn. Geliştirme ekibi, yönetim tarzı, süreç olgunluğu, konunun zorluğu, vb.). Bunu biraz daha iyi kapsamlandırmak için, aşırı basitleştirmeleri süpürmekten başka bir şey hakkında konuşabiliriz, sorunuzu yeniden ifade edeceğim:

Hangi koşullar altında, varsa, geç çalışan bir yazılım geliştirme projesine ekip üyeleri eklemek, mevcut gemi tamamlanıncaya kadar çalışmasına izin verildiyse, gerçek gemi tarihinde bir kalite kalitesinde düşüşe neden olabilir?

Bunun gerçekleşmesi için gerekli olduğunu ancak yeterli olmadığını düşündüğüm bir takım şeyler var (belirli bir sırayla):

• Projeye eklenmesi önerilen kişiler:
  • En azından projenin problem alanı hakkında makul bir anlayış
  • Projenin dilinde ve verilecek görevler için kullanacakları belirli teknolojilerde yetkin olmak
  • Yeterlilikleri, mevcut en zayıf ya da en güçlü üyeye göre çok daha az ya da çok daha büyük olmalıdır. Zayıf üyeler mevcut personelinizi üçüncül problemlerle boşaltırken, çok güçlü olan yeni bir kişi ekibi yaptıkları ve yaptıkları her şeyin nasıl yanlış olduğu konusunda bozar.
  • İyi iletişim becerilerine sahip olmak
  • Çok motive olun (örneğin, üretmeden bağımsız çalışabilmek)
• Mevcut ekip üyeleri aşağıdakilere sahip olmalıdır:
  • Mükemmel iletişim becerileri
  • Mükemmel zaman yönetimi becerileri
• Proje sorumlusu / yönetimi şunları içermelidir:
  • İyi önceliklendirme ve kaynak tahsisi yetenekleri
  • Mevcut ekip üyelerinden yüksek düzeyde saygı
  • Mükemmel iletişim becerileri
• Proje aşağıdakilere sahip olmalıdır:
  • İyi, tamamlanmış ve belgelenmiş bir yazılım tasarımı özelliği
  • Halihazırda uygulanmış olan şeylerin iyi dokümantasyonu
  • Açık sorumlulukların yerine getirilmesine izin veren modüler bir tasarım
  • Gerekli kusur seviyesi için kalite güvencesi için yeterli otomatik süreçler Bunlar aşağıdakileri içerebilir: birim testleri, regresyon testleri, otomatik yapı dağıtımları, vb.)
  • Şu anda ekip tarafından yerinde ve kullanımda olan bir hata / özellik izleme sistemi (örn. Trac, SourceForge, FogBugz, vb.).

Sevk tarihi olmadığını tartışılması gerektiğini ilk şeylerden biri olduğunu olabilir kaymış olması özellikleri kesilebilir olsun, ve ikisinin bazı kombinasyonlar sağlayacak eğer mevcut personel ile salınımını karşılamak için. Çoğu zaman, yatırımın değerine eşit değer sağlamayacak takımın kaynaklarını gerçekten sarsan birkaç özellik. Bu nedenle, projenizin önceliklerini her şeyden önce ciddi bir inceleme yapın.

Yukarıdaki paragrafın sonucu yeterli değilse, yukarıdaki listeyi ziyaret edin. Program fişini erken yakaladıysanız, doğru ekip üyelerinin doğru zamanda eklenmesi sürümü kurtarabilir. Ne yazık ki, beklenen gemi tarihine ne kadar yaklaşırsanız, insan eklerken o kadar çok şey ters gidebilir. Bir noktada, hiçbir değişikliğin (mevcut geliştirme dalını göndermekten başka) sürümünüzü kaydedemeyeceği "geri dönüşü olmayan noktayı" geçersiniz.

Devam edebilirdim ama bence önemli noktalara değindim. Proje dışında ve kariyeriniz açısından, şirketin gelecekteki başarısı vs. gelecekte önlemek için almak. Geç bir proje genellikle şunlardan biri olduğunuz için oluşur:

• Başlamadan önce geç kalmıştı (zamandan daha fazla şey) ve / veya
• 1 saat, 1 gün kaymış.

Umarım yardımcı olur!

Yalnızca kaynak odaklı bir projeniz varsa yardımcı olur.

Örneğin, şunu düşünün:

4 x 6 metre gibi büyük bir poster boyamanız gerekiyor. Büyük bir poster, muhtemelen iki veya üç kişiyi önüne koyabilir ve paralel olarak boyamasını sağlayabilirsiniz. Ancak 20 kişinin önüne yerleştirilmesi işe yaramaz. Ayrıca, berbat bir poster istemiyorsanız, yetenekli insanlara ihtiyacınız olacak.

Ancak, projeniz hazır harfleri olan zarfları doldurmaksa ( MIGHT kazandınız gibi! ), Ne kadar çok kişi eklerseniz, o kadar hızlı gider. İş yığınlarını doldurmada bazı ek yükler vardır, bu nedenle bir kişi priniz olan noktaya kadar fayda sağlayamazsınız. ancak 2 veya 3 kişiden çok daha fazla avantaj elde edebilirsiniz.

Eğer projeniz kolayca küçük parçalara ayrılabilirse ve ekip üyeleri hızlı bir şekilde hızlanabiliyorsa (örneğin ... anında), o zaman daha fazla kişi eklemek projeyi daha hızlı, bir noktaya kadar hızlandıracaktır.

Ne yazık ki, dünyamızda pek çok proje böyle değil, bu yüzden docgnome'un Mythical Man-Month kitabı hakkındaki ipucu gerçekten iyi bir tavsiye.

Belki aşağıdaki koşullar geçerliyse:

1. Yeni programcılar zaten projeyi anlıyor ve rampa süresine ihtiyaç duymuyor.
2. Yeni programcılar zaten geliştirme ortamına hakim.
3. Geliştiricileri ekibe eklemek için yönetici süresine gerek yoktur.
4. Ekip üyeleri arasında neredeyse hiç iletişim gerekmez.

Tüm bunları bir kerede ilk gördüğümde size haber vereceğim.

Efsanevi Adam Ayına göre, geç bir projeye insanları eklemenin ana nedeni daha sonra O (n ^ 2) iletişim yüküdür.

Bunun temel bir istisnasını yaşadım: bir projede sadece bir kişi varsa , neredeyse her zaman mahkumdur. İkincisi eklemek neredeyse her seferinde hızlandırır. Çünkü bu durumda iletişim genel değildir - düşüncelerinizi netleştirmek ve daha az aptalca hata yapmak için yararlı bir fırsattır.

Ayrıca, sorunuzu ne zaman yayınladığınızı açıkça bildiğiniz gibi, Efsanevi Adam-Ay'ın tavsiyesi sadece geç projeler için geçerlidir . Projeniz henüz geç değilse, insan eklemenin daha sonra başaramayacağı oldukça olasıdır. Elbette doğru yaptığınızı varsayarsak.

Mevcut programcılar tamamen yetersizse, yetkili programcılar eklemek yardımcı olabilir.

Çok modüler bir sisteminizin olduğu ve mevcut programcıların çok izole bir modülde başlamadığı bir durum hayal edebiliyorum . Bu durumda, projenin sadece bu bölümünün yeni bir programcıya atanması yardımcı olabilir.

Temelde Efsanevi Adam Ayı referansları doğrudur, uydurduğum gibi başka davalar hariç. Bay Brooks, belirli bir noktadan sonra, bir projeye yeni programcılar eklemenin ağ ve iletişim maliyetlerinin üretkenliklerinden elde ettiğiniz faydalardan daha ağır basacağını göstermek için sağlam bir araştırma yaptı.

• Yeni insanlar test etmeye odaklanırsa
• Yeni bağımlılıklar oluşturmayan bağımsız özellikleri yalıtabiliyorsanız
• Projenin bazı yönlerini (özellikle görsel tasarım / düzen, veritabanı ayarlama / dizin oluşturma veya sunucu kurulumu / ağ yapılandırması gibi kodlamayan görevler) dikey hale getirebiliyorsanız, bir kişi bunun üzerinde çalışabilirken diğerleri uygulama koduyla devam edebilir
• İnsanlar birbirlerini ve teknolojiyi, iş gereksinimlerini ve tasarımı, birbirlerinin ayak parmaklarına ne zaman adım atacaklarını ve bundan nasıl kaçınacaklarını bilen bir şeyler yapabilecek kadar iyi biliyorlarsa (bu, tabii ki, zaten böyle değilse düzenlemek oldukça zor)

Ancak o geç aşamada, henüz kimse tarafından ele alınmayan bazı bağımsız (projenin diğer bölümleriyle neredeyse% 0 etkileşim) görevleriniz olduğunda ve o alanda uzman birisini ekibe getirebilirsiniz. Bir ekip üyesinin eklenmesi, ekibin geri kalanı için aksamaları en aza indirmelidir.

Programcı eklemek yerine, idari yardım eklemeyi düşünebilirsiniz. Dikkat dağıtan şeyleri kaldıracak, odağı iyileştirecek veya motivasyonu artıracak her şey yardımcı olabilir. Buna hem sistem hem de yönetimin yanı sıra öğle yemeği almak gibi daha belirgin şeyler de dahildir.

Açıkçası her proje farklıdır, ancak çoğu geliştirme işinin geliştiriciler arasında belirli bir işbirliğine sahip olduğundan emin olabilirsiniz. Bu durumda, benim deneyimim, taze kaynakların onları hızlandırmak için güvendikleri insanları istemeden yavaşlatabileceği ve bazı durumlarda bu sizin anahtar insanlarınız olabilir (bu arada genellikle 'anahtar' insanlar bir yeniyi yetiştirme zamanı). Onlar ne zaman olduğu hıza kadar işlerini takımın geri kalanı ile kurulan 'kurallara' veya 'iş kültürü' sığabilecek garantisi yoktur. Yani yine, yarardan çok zarar verebilir. Yani bir yana, bunlar yararlı olabileceği durumlar:

1) Yeni kaynağın, diğer geliştiricilerle minimum etkileşim ve daha önce gösterilmiş bir beceri seti gerektiren sıkı bir görevi var. (ör. mevcut kodu yeni bir platforma taşımak, mevcut kod tabanında şu anda kilitli olan ölü bir modülü harici olarak yeniden düzenlemek).

2) Proje, yeniyi daha hızlı hale getirmeye ve çalışmalarının daha önce yapılanlarla uyumlu olmasını sağlamak için yol boyunca onlara rehberlik etmeye yardımcı olmak için diğer daha kıdemli ekip üyelerinin zamanının paylaşılabileceği şekilde yönetilir.

3) Diğer ekip üyeleri çok sabırlılar.

İşin sonuna doğru insanları eklemek şu durumlarda hızlandırabilir:

1. İş paralel olarak yapılabilir.

2. Eklenen kaynaklardan tasarruf edilen miktar, proje ile deneyimli kişilerin deneyimsiz olanlara bir şeyler açıklamalarını sağlayarak kaybettikleri zamandan fazladır.

EDIT: Bahsetmeyi unuttum, bu tür şeyler çok sık olmaz. Genellikle bir tabloya basit CRUD yapan yönetici ekranları gibi oldukça basit şeylerdir. Bugünlerde bu tür araçlar çoğunlukla otomatik olarak oluşturulabilir.

Yine de bu tür işleri yapan yöneticilere dikkat edin. Kulağa harika geliyor, ancak gerçekte projeden önemli bir zaman ayırmaya yetmiyor.

• Henüz başlatılmamış bağımsız modüller
• Entegre edebilecekleri geliştirme araçlarından yoksundur (otomatik bir yapım yöneticisi gibi)

Öncelikle, şu anda gelişmekte olan insanların yolundan uzak durmalarını sağlayan şeyleri düşünüyorum. Efsanevi Adam Ayına katılıyorum, ama aynı zamanda her şeyin istisnaları olduğunu düşünüyorum.

Bir ekibe insan eklemek bir projeyi projenin kendisine eklemekten daha fazla hızlandırabilir.

Çok fazla eşzamanlı projeye sahip olma sorunuyla sık sık karşılaşıyorum. Yalnızca bu projeye odaklanabilseydim bu projelerden herhangi biri daha hızlı tamamlanabilirdi. Ekip üyeleri ekleyerek diğer projelerden geçiş yapabilirim.

Tabii ki, bu, büyük projeleri devralan ve bağımsız olarak öğrenebilen yetenekli, kendini motive eden geliştiriciler tuttuğunuzu varsayar. :-)

Ekstra kaynak mevcut ekibinizi tamamlarsa ideal olabilir. Örneğin, üretim donanımınızı kurmak üzereyseniz ve veritabanının aslında sadece iyi sonuçlar (aksine ekibinizin etki alanı uzmanları olarak bildiği) döndürmek yerine ayarlandığını doğrulamak istiyorsanız, bir sonraki projede çalışan iyi bir dba'dan ödünç alma zamanı çok fazla eğitim masrafı olmadan takımı hızlandırabilir

Basit ifadeyle. Hızlanmak, üretken olmak ve mevcut kaynaklarla öğretmek için harcanan zamanı çıkarmak için ek kaynakların harcanan zaman miktarı dışında birisinden alacağınız üretkenlik ile kalan zamanı karşılaştırmak gelir. Anahtar faktörler (önem sırasına göre):

1. Kaynağın onu almakta ne kadar iyi olduğu. En iyi geliştiriciler yeni bir siteye yürüyerek gidebilir ve neredeyse anında küçük bir yardımla hataları anında üretebilir. Bu beceri nadirdir ancak öğrenilebilir.
2. Görevlerin ayrılabilirliği. Mevcut geliştiricileri takmadan ve yavaşlatmadan nesneler ve işlevler üzerinde çalışabilmeleri gerekir.
3. Projenin karmaşıklığı ve mevcut belgeler. Eğer bir vanilya en iyi uygulama ASP.Net uygulaması ve ortak iyi belgelenmiş iş senaryoları varsa, iyi bir geliştirici hemen sıkışmış olabilir. Bu faktör her zamankinden daha fazla mevcut kaynakların öğretime ne kadar zaman ayıracağını ve dolayısıyla yeni kaynakların ilk olumsuz etkisini belirleyecektir.
4. Kalan süre. Bu da genellikle yanlış tahmin edilir. Genellikle mantık sadece x haftamız kalır ve birini hızlandırmak x + 1 hafta sürer. Gerçekte, proje SİZİN geçecek ve aslında 2x haftalık geliştirici kalmaya devam edecek ve daha sonradan daha fazla kaynak elde etmek yardımcı olacaktır.

Bir ekibin programlamayı eşlemek için zaten kullanıldığı durumlarda , eşleştirme konusunda zaten yetenekli olan başka bir geliştirici eklemek , özellikle geliştirme bir TDD stiliyle devam ediyorsa, projeyi yavaşlatmayabilir.

Yeni geliştirici, kod tabanını daha iyi anladıkları için yavaş yavaş daha üretken hale gelecek ve yanlış anlaşılmalar ya çiftleri tarafından ya da her check-in öncesinde çalıştırılan test paketi tarafından çok erken yakalanacaktır (ve ideal olarak bir kontrol olmalıdır. en az on dakikada bir).

Ancak, ek iletişim yüklerinin etkilerinin dikkate alınması gerekir. Projenin mevcut bilgisini çok fazla seyreltmemek önemlidir.

Geliştiricilerin eklenmesi, ek geliştiricilerin katkıda bulunduğu üretkenliğin, bu geliştiricilerin eğitimi ve yönetiminde kaybedilen verimliliği aşması anlamlıdır.