Takıma nasıl yeni bir geliştirici eklenir

Sadece 2 geliştiriciden oluşan küçük bir şirket işletiyorum. Müşterilerimizden biri için çok büyük bir uygulama inşa ediyoruz. Bu projedeki gelişme 1,5 yıl sürdü.

Şimdi bu müşteri önemli bir sponsorluk sağladı ve bu projeyle ilgili etkinlikler düzenliyorlar. Şimdi 2 ay içinde son bir tarihimiz var ve bunu kaçıramayız.

Takıma yeni bir geliştirici eklemeyi düşünüyoruz ve entegrasyonuna yardımcı olmak için ne yapabiliriz diye merak ediyorum.

Durum bu:

• Brooks Yasası'nın eşiğine yaklaşıyoruz - yeni geliştiriciler eklerken nokta-üretken olacak.
• Uygulama nispeten iyi tasarlanmış, ancak uygulama bazı noktalarda kaotiktir (özellikle eski kod).
• Sadece daha yeni kod için birim testleri var. Bu proje başladığında düzenli olarak testler yapmadık.
• Belgeler ve yorumlar eksik.
• Uygulama hem büyük hem de karmaşık.
• Müşteri, projesi hakkında neredeyse her detayı çok net ve "programcı dostu" bir şekilde yazdı.

Şimdi bir kişi eklemek iyi bir fikir mi? Öyleyse, yeni geliştiricinin takıma entegre olmasına yardımcı olmak için ne yapabiliriz?

DÜZENLE:

Sponsor önümüzdeki bahar için internet tabanlı bir spor etkinliği düzenliyor. Yılın belirli bir gününde başlamalıdır. Değiştiremeyiz.

Geliştiricilerimizin (ben iki kişiden biriyim) yapmamız gereken şey:

• Mevcut uygulamanın tamamlanması (yapılacak işin yaklaşık% 25'i).

• Bu etkinliğin organizasyonu için gerekli olan yeni bir modül oluşturma (yapılacak işin yaklaşık% 75'i). Bu yeni modül ana programın API'sini anlamadan geliştirilemez.

Kesin bir zaman tahmini yapamam, ama riskli durumdayız.

Yapılacak en iyi şey, yeni geliştiriciyi ateşe atmak değil, geliştiricinin atlamakta zorlanmaması gereken bazı işlevsellik ve / veya hata düzeltmelerini yapmaktır. Bir kişinin tüm mimariyi, gereksinimlerini ve kod temelini aynı anda bilmesini gerektirmeyen iş gerektiren bir alan bulun. Belki sistemi daha hızlı öğrenmek için dokümantasyon üzerinde çalışması gerekir.

Ekibe yeni bir geliştirici eklemek yerine, şirketinizin iş yükündeki geçici artışı sağlamak için iki-üç aylık dönem için deneyimli bir danışman eklemeyi düşünün. Buradaki fikir sıfıra yakın başlama zamanı ile başa çıkabilecek birini elde etmektir, ancak aynı zamanda ekibinize en iyi şekilde yardımcı olmak olmayabilir.

İş yükündeki artışın geçici olmadığını düşünseniz bile, şimdi muhtemelen ekibinizi organik olarak büyütmek için en iyi zaman değil: üçüncü bir geliştirici eklemek, proje süresinin baskısı olmasa bile bir ekip için stresli bir şeydir; Sıkı teslim tarihi yalnızca geçişi daha da kötüleştirir.

Tradeoff, geçici bir yardım karşılığında, bir yabancı tarafından yazılmış kodu alacağınız yönünde. Bu riski azaltmak için, her ikinizin de tüm kod incelemelerini kendisiyle yaptığınızdan emin olun. Tüm ünite testlerini de incelediğinizden ve anladığınızdan emin olun.

Şimdi bir kişi eklemek iyi bir fikir mi?

Hayır. Mümkünse müşterinin bunun yerine kapsamı azaltma konusunda hemfikir olmasını sağlayın.

Bu geç bir kişiyi eklemek önemli bir risk oluşturacaktır ve son tarih (anlaşılan kadarıyla) zorlanamaz.

Yapma

Oysa.

Geleneksel görünüm

Sorunuzda , Brooks'un Efsanevi Adam Ayındaki yasasına bakınız .

Geç bir yazılım projesine insan gücü eklemek daha sonra yapar.

Brook'un yasasını görmezden gelmek bir bedel taşır. Çoklu görev yapma. Minimum Uygun Ürününüzün (MVP) teslimatına odaklanın. Ardından enerjinizi yeni bir ekip üyesini işe alma, kaynak bulma, eğitim ve yönetmeye odaklayın.

İki ay çok kısa. Bir yakma listesi ile işe alım planlayın ve ne kadar zaman alıcı olabileceğini göreceksiniz.

Larry Page ve Sergei Brin Google'ın ilk ekibini seçerek iki yıl geçirdi. Üç numaralı çalışan için seçiminiz de dikkatli olmalıdır.

Çevik, Yeni Millenium Görünümü

Rekabet, artık Mythical Man-Month (1960'ların ortalarında) yazıldığı döneme kıyasla dinamik ekip çalışmasını daha da hızlandırıyor. Bir şirkette uzun kariyer bitti. Şimdi projeler ve şirketler arasında sık sık göç ediyoruz. Hızlı ekip oluşturma başarı yaratır. Yavaş rampa, ciddi bir sınırlayıcı faktördür. Harika örnekler açık kaynaklı projelerden, başlangıçlardan ve takım projelerinin bilgisayar bilimleri derslerinde kullanımının artmasından kaynaklanıyor.

Potansiyel olarak, Çevik ekipler kısıtlamaları programlarına dahil eder. Geç değiller, çünkü mevcut kaynaklar için optimize edildiler. Yeni personelin entegrasyonu bir kısıtlamadır ve kısa ve uzun vadeli hedefler arasında bir takas olarak kabul edilir. Çevik ekip sürekli olarak kodu bütünleştirir, öyleyse neden insanlar da değil?

Çevik ekibin yeni personel için teknik ve sosyal entegrasyon kullanabilirsiniz:

• günlük israflar
• çiftler programı
• yeniden düzenleme
• eksik birim testleri ekleme
• yağsız belgeleme besi
• kod incelemeleri

Kurbanlık Kuzu

" Çevik Yazılım Geliştirmenin Örgütsel Kalıpları" nda James Coplien, grup dinamiklerini ve yeni ekip üyeleri eklemenin maliyetlerini tartışıyor. Onun “Kurban Kuzu” kalıbı, tüm mentorluğu ve eğitimi tek bir kişiye atar ve ekibin geri kalanını kesintiye karşı korur.

Uygulamayı düşünmek isteyebileceğiniz bir strateji.

Diğer bir strateji, her gün belirli saatlerde yeni işe alımlardan gelen soruları kapsayan yeni işe alım danışmanları görevlendirmektir. Yalnız bir adamı ayırabilirseniz, belki sabahları veya öğleden sonraları kesintisiz çalışır ve sırasıyla öğleden sonraları veya sabahları soruları cevaplar. İçinde bulunduğum grupta geçen yaz on stajyer vardı, bu yüzden birçok insan çok rahatsız edildi.

Halen mentorluk, bir kişi tarafından, esas olarak sabah işimizden hemen sonra ve hemen (08: 30-9: 15, kombine) ve öğleden sonra 12-3: 30 arasında (öğleden sonra 07: 00-30: 30 arasında) yapılmaktadır. pm).

Brook Yasası'ndan bahsettiğini duydum. Güzel bitti. Başka bir geliştirici eklemenin temel problemi, onları hızlandıracaklar ve projenin neresinde olduğunuzla ilgili onlarla senkronize olma durumunun tepkisidir. Bu nedenle, üçüncü bir geliştiriciyi almaya karar verirseniz, şunu deneyeceğim:

• Yeni çocuğa en yüksek maliyetlerin düşük olduğu ve mümkün olduğunca çabuk gidebileceği bir alan verin. Bu, kimi işe aldığınıza ve hangi becerilere sahip olduklarına bağlı olacaktır.
• Senkronizasyon ek yükünün daha az olması için bu alanın uygulamanın diğer alanlarıyla gevşek bir şekilde bağlandığından emin olun. Yoğun DB çalışması yapmak için onu göndermek ve tabloları yeniden düzenlemek çok fazla olabilir.
• Moralinizi yükseltmek için elinizden geleni yapın. Diğerlerinin de belirttiği gibi, yeni bir ekip üyesi eklemek stresli olabilir, bu nedenle belki gazlı içeceklere yatırım yapmak yardımcı olabilir.

Eğer Brook Yasasını sıkı bir şekilde uygularsan, takımını asla büyütemezsin.

İşin püf noktası, şu anki takımınıza çok fazla yavaşlama yaşamadan yeni kişiyi etkilemektir. Sonunda yeni insan hızlandıracak ve kamburdan kurtulabilirsiniz.

Senin durumunda? Yeni kişinin tüm eksik birim testlerini yazmasını tavsiye ederim.

1. Bunlar, sizi herhangi bir Brooks yavaşlamasından daha hızlı yakacak olan regresyon hatalarına karşı bir koruma olarak şiddetle ihtiyaç duyuyor.
2. Yeni kişi sisteminizin cesaretini öğrenecek. Ateşle deneme biraz - ama onların çıktıları üretim koduna girmiyor, orada çok az risk.
3. Diğer ekip üyelerinin ne kadar süre alabilecekleri konusunda kesin bir sınır koyun. Örneğin, soruları sıraya koymalarını ve son tarih gelinceye kadar günde yalnızca 30 dakika boyunca diğer ekip üyeleriyle etkileşime girmelerini sağlayın.

Ayrıca, bununla yüzleşelim: Yeni bir kişi alıp almadığınıza bakmaksızın kapsamı ve müşteri beklentilerini yönetmek zorunda kalacaksınız. Kazanç bir sonraki döngüde gelir.

Ed Yourdon, Brook Yasası hakkında harika bir yorum yaptı. Dedi ki: Tabii ki, insanları eklemek sizi yavaşlatır - ancak bir proje risk altındayken, yönetimin yeni insanları getireceği tek zamandır. Öyleyse: onları alın, mevcut sürümdeki etkiyi en aza indirin ve mümkün olan en kısa sürede kötü performans gösteren sanatçılardan kurtulun. Bu sayede zamanla güçlü bir takım kurabilirsiniz.

Eğer, mevcut 2 geliştiricinin yardımcı olabileceği büyük teslim tarihlerine yoğunlaşması için zaman ayıracak, ona verebileceğiniz başka projeler üzerinde çalışıyorsanız.

Orijinal çalışmanın% 25'ini ve yeni çalışmayı tamamlamanız gerektiğini söylüyorsunuz. Ve bunu iki ay içinde yapmanız gerekir - işin% 75'ini yapmanız 18 ayınızı aldı. Çok açık olmak gerekirse, bu benim tahmin kabiliyetinizin kod odaklı bir programcı için ortalama bir değer olduğunu gösteriyor - yani, işlerin sizi gerçekte yaptıkları gibi yarısı üçte birinin alacağını düşünüyorsunuz.

Heroics, sözleşme yaptığınız ürünü teslim etmenize izin verebilir, ancak size veya müşterinize hiçbir iyilik yapmaz. Bu şartlar altında, sert ve böcek baskın olacak ve dumanlar üzerinde koşuyor olacaksınız.

Kiralamak için harcadığınız zamanın da uygunluk durumunuz üzerinde önemli bir etkisi olacağını aklınızda bulundurun - bu sadece bir haftasonunda yapabileceğiniz bir şey değildir, uygun olan yetenekli çalışanları bulmak zaman alır. En az birkaç hafta araştırarak, görüşerek vb. Geçirmeyi bekleyin. Siz ve mevcut çalışanınızın, arama yaparken haftada yaklaşık 10 saat üretken zaman kaybedeceğini bekleyin.

Benim önerim:

Müşterinizle oturun, başınızın üstünde olduğunuzu açıklayın ve kapsamı en aza indirgemek için onunla birlikte çalışın.

Düzenle Sadece burada tarihi gördüm. Peki nasıl bitti? (Üç aylık bir soru gönderdiğiniz için teşekkür Ars Technica;)

Araştırmayı düşündüğüm birkaç farklı yol var:

1. Son tarihi geçinceye kadar yeni geliştiriciyi işe almaya devam edin, böylece alan bilgisini yeni adama aktarmaya odaklanmayı kolaylaştırın. Bu benim tercihim olurdu, çünkü birkaç şekilde biraz zorlayıcı olabilir.

2. Yeni geliştiriciyi belgeler, ünite testleri ve mevcut kodlardan hiçbirini değiştirmeyen diğer şeyler üzerinde çalışmaya getirin. Bu, mevcut iş yükü üzerindeki etkiyi en aza indirmeye çalışmak için yeni adamı getirirseniz önereceğim şey olurdu.

Tarih çoktan geçti, ancak bunu daha sonra okuyan herkes için.

Göz önünde bulundurulması gereken en önemli şey, bu durumda müşterinin sizinkinden daha fazla kaybedeceğidir. Zaten çok para harcadılar ve işlerini bozabilecek ya da bozabilecek önemli bir olayı var. Zaten onların parası var ve tek bir müşteriyi kaybetmek işinizi bozmamalı. Eğer öyleyse, o zaman korkunç proje yönetimi dışında başka ciddi iş sorunları var.

En iyi seçeneğiniz, temel bir işlevsellik alt kümesiyle pazarlık etmek ve daha sonra bunu yapmak için fazla mesai yapmaktır. Daha küçük bir alt kümenin olmasını sağlayamazsanız veya bu durumda fazla mesai yapmaya istekli değilseniz, muhtemelen iş dünyasında olmamalısınız. Bu, diğer müşterileri beklemeye almak anlamına gelebilir, ancak diğer müşterilerinize 3 yıl boyunca hiçbir ödeme yapmadığını tahmin ediyorum, bu yüzden kaynaklarınızı paranın olduğu yere koyun.

Kapsamı aşağıya müzakere etmeye istekli olmazlarsa, başarısız olursunuz.

Bu projeyi tamamen zaman içerisinde teslim etme şansı yoktur. Şimdiye kadar teslim edilmesi 18 ay süren bir projede% 25 kaldığınızı düşünüyorsanız, en az 6 ayınız kaldı (~ 2 geliştirici). Başka bir kişi eklemek bunu önemli ölçüde değiştirmeyecektir.

Belirtildiği gibi, işe alım zaman alır. Benim deneyimim bunun en azından bir ay sürmesi. Sonra eğitim ekleyin ve zamanınız doldu.

Umarım bu sizin için işe yaradı.