Yeni ekip üyelerini projeden nasıl haberdar edebilirim? [kapalı]

Yazılım ekibi için 1-2 yeni mühendis kiralamak üzereyiz (3 geliştiriciden, 1 test ediciden oluşan).

Bunları ekibe entegre etmenin adımları nelerdir?

Fikirlerim:

• belgeleri okuyun (kodlama standartları, kullandığımız geliştirme metodolojilerindeki belgeler)
• mevcut kodu okumalarını sağlayın
• onlara basit görevler ver
• sonunda, kod bölümünden sorumlu hale getirin

Başka ne yapabiliriz?

Proje bir sağlık sektöründe (ultrason sistemi) ve zaten 5 yıl sürüyor. Yıllık sürümlerimiz var ve 1-2 mühendis eklemek istediğimizde bir sürümü bitirmek üzereyiz.

Proje bakım aşamasındadır (eski kodu yeniden düzenleme ve yeni özellikler ekleme). İşler neredeyse programa göre (az çok).

Kariyerim boyunca birçok farklı kod tabanını hızlandırmak zorunda olan birinden geliyor, işte size önereceğim:

1. Ürünün ne yaptığına aşina olabilmeleri için ürünü kullanma ile ilgili etkinliklerle kısa bir süre (belki bir veya iki gün) geçirin. Bu, hataları doğrulamak veya KG test planlarını uygulamak veya kullanıcı eğitiminden geçmek olabilir.
2. Küçük, yerelleştirilmiş hatalar üzerinde çalışın. Bu, mühendisi, mimariyi çok fazla öğrenmekle uğraşmadan uygulamanın nasıl oluşturulacağını ve hata ayıklanacağını öğrenir.
3. İdeal olarak, yerelleştirilmiş küçük bir yeni özellik yazın. Bu, bir kod parçası yazmalarını sağlar ve yazdıklarında, yeni kodlarının çalışması gereken çevredeki kod parçalarına aşina olurlar.

Oradan, mühendislerin deneyim düzeyine ve yeteneğine bağlı olarak zaman içinde görevlerin kapsamını ve karmaşıklığını genişletin. Bu, geliştiricinin kod tabanı hakkındaki bilgilerini doğal olarak genişletmesine izin verecektir.

Sadece görevleri (dokümantasyon veya kod) okumaktan kaçınırım. Belgeleri okumak gerçekten çok sıkıcı oluyor ve rastgele bir kod okumak yararlı olmayacak, çünkü üzerinde çalışacak herhangi bir bağlam olmayacak. Ürün ve kod tabanını zaten bildiğinizde kod incelemeleri için kodu okumak yeterince zor. Yepyeni bir mühendisin sadece kodu okuduğundan faydalı hiçbir şey göremiyorum.

Benim düşüncem, çoğu insanın belgeleri okumaya toleransının oldukça düşük olmasıdır (Bir veya iki gün için iyi, ancak bunun ötesinde muhtemelen biraz daha pratik bir şey yapmak için kaşıntılı olacaklar).

Uygulamanın kendisini makul bir şekilde anlamadan bir uygulamanın kodunu gerçekten anlayabileceğinizi sanmıyorum. Yazılımın muhtemelen kullanıcı olarak 'oynayabileceği' birçok işlevselliği vardır; sonunda test edebilmeleri gerekecek, bu yüzden onu nasıl kuracaklarını, yapılandıracaklarını ve onunla ortak görevleri gerçekleştireceklerini bilmelerinin oldukça önemli olduğunu umuyorum.

Kişisel olarak, üst düzey bir mimariye genel bakışın, işlerin nasıl çalıştığına dair temel bir his elde etmek için genellikle oldukça kullanışlı olduğunu düşünüyorum - Belki sadece ilk haftalarında bir veya daha fazla kıdemli bir mühendisin zamanını (veya gerekirse kendiniz mi? ana uygulamanın temel somun ve cıvataları. örneğin, tüm alt sistemleri ve şeylerin birbirine nasıl bağlandığını anlamak, hangi parçaların 3. taraf yazılım / kütüphaneler tarafından ele alındığını ve hangi parçaların şirket içinde tutulması gerektiğini bilmek. (Kuruluşunuz gerçekten olağanüstü kalitede güncel belgelere sahip olmadıkça, sanırım birisi doğrudan bir beyaz tahta kullanarak onlara açıklama yapmadan bu tür şeyleri kavramanın hiçbir yolu yoktur: - ))

Onlara "elden" bir şey vermek için, bakım / hata takip görevleri, onları bir süre hızlandırmak için iyi bir yol olabilir (birkaç hafta / ay?) - belirli işlevsellik alanlarının olduğu durumlarda anlaşılması, test edilmesi ve hata ayıklanması gerekir; Kod, gereksinimler, şirket tarafından kullanılan araçlar, geliştirme süreçleri ve bir bütün olarak ürün (ler) hakkında bilginin geliştirilmesine yardımcı olurken, umarım geliştirme ekibinin geri kalanından çok fazla zaman geçirmeye gerek yoktur

Öncü olarak yeni geliştiricilerle en az 2 gün geçiriyorum. Kaçınılmaz soruyu "ilerlemen nasıl?" olmalı. Herhangi bir yeni toplulukta sığacak korku var ... hataları gizliyoruz, mükemmel davranıyoruz, işleri olduğundan daha iyi yapıyoruz, zorluğu azaltıyoruz. Biriyle birlikte 2 gün geçiren bir yönetici, kültürlerinin ne olduğunu bilmediğini ve örnek olarak liderlik etmelerini sağlar. Yeni kodlayıcıların nereden geldiğiniz ve ne kadar uzakta olduğunuz hakkında bir tarih dersine ihtiyacı var. Belgeler sadece görev adaletini yapmıyor.

Endüstride sadece 10 aydır çalışıyorum (Yerleşimde) ancak aşağıdakilerin bana yardımcı olduğunu gördüm:

• Diğer geliştiricilerle birlikte çalışmak ve sorunları nasıl ele aldıklarını gözlemlemek.
• Yazılımı test etmek yardımcı oldu, x özelliğini test etmem gerekir, bu da x özelliğindeki belgeleri okuduğum anlamına gelir. Bunu çok yaptım, yardımcı oldu.

Her ikisi de bana oldukça yardımcı oldu. İyi şanslar.

Ben yüksek seviyeden alçaka giderdim.

Uygulamayı mümkün olan en kısa sürede tanıtın

En önemli şeylerden biri, geliştiricinin ne üzerinde çalışacakları hakkında bir fikre sahip olmasıdır. Demo sırasında, son geliştirme aşamasında olan bazı şeyleri ve uygulamanın gidiş yönünü belirtin.

Üst düzey mimariyi açıklar

Bu da çok önemli. Yeni geliştiricinin soruları dinlemesine ve sormasına izin verin. Bunu, umarım devreye girecek ve size yardımcı olacak diğer geliştiricilerle grup çalışması olarak yapın. Bu, yeni geliştiriciye açıkça ve dürüstçe konuşmanın uygun olduğunu bildirecektir.

Harika bir yerleşik belge hazırlayın

Harika bir yerleşik belgeye sahip olmak sadece yeni geliştiricilere değil, eski geliştiricilere de yardımcı olur. Beklentileri, faydalı bağlantıları ve ortam kurulum bilgilerini içerebilir. (Yeni bir bilgisayar aldığımda çevremizi kurmak için on-board'umuzu kaç kez kullandığımı size söyleyemem ...) Bu iyi yapılandırılmış ve noktaya gelmeli ve oyalanmamalı, biraz detay.

Soru sormaya teşvik edin (ve cevaplamaya hazır olun)

Cevaplarla onlara rehberlik edin, ancak ne yapacaklarını söylemeyin. Onlara ipuçları verin ama sonunda kendi kendilerine çözmelerine izin verin.

Diğer ekip üyelerinin yeni gelenleri karşılamalarına yardımcı olun

Birisi bir takıma katıldığında madalyonun iki yüzü vardır. Takımın yeni geliştiriciyi de ağırlayacak araçlara sahip olması gerekiyor.

Küçük bir görev alsınlar

Demoya uygun projeye yeni ve görünür bir şey eklemelerine izin verin. Demo yapıldığında, bunu kimin yaptığını ve ne kadar iyi bir iş yaptığını söyleyin. Bu gerçekten benlik saygısını artırabilir. Ne kadar hızlı değer katıyorlarsa, takımın bir parçası olduklarını o kadar hızlı hissederler. Ne kadar hızlı olursa, ellerinden gelenin en iyisini yapmaya zorlanmış hissedeceklerdir.

Kendilerini gittikçe daha rahat hissettiklerinde daha zor görevlere girmeye teşvik edin

İyi adaylar bunu doğal olarak yapacaklardır.

İçinde bulunduğum (ve yararlı bulduğum) bir "yönelim" akışı, şu çizgiler boyunca bir şeydi:

1. Bileşenlerin ne olduğunu, uyumunu ve genel mimariyi "Büyük Resim" e veren kısa bir sunum.
2. Kodun bir özeti, bana atanan bileşenlerin ana mantığını işleyen işlevlere giriş. Kodlama kuralları ve üslubu ile ilgili bazı şeyleri kapsamıştır.
3. Bir grup açık sorun ve düşük öncelikli hatalar atandı (bunlar bana atanan bileşene büyük ölçüde yerelleştirildi ve oldukça basitti).
4. Uygulama aracılığıyla hata ayıklaması ve deşifre edemediğim şeylerle ilgili yardım istemem bekleniyordu.
5. Düzeltme yapıldıktan sonra, entegrasyona bırakma sürecini (kod inceleme, dev-seviyesi testi vb.) Geçtim.
6. Ayrılan kalan görevler / hatalar için tekrarlayın.

Bu yaklaşımın (ve varyasyonlarının) faydalı olacağını düşünüyorum çünkü:

• Bu daha uygulamalı ve nispeten bağımsızdı (sürekli el tutma vb.). Böylece, yeni kişinin koda alışması ve ekipte işlerin yapılma şekli için yeterli alan / zaman sağlar.
• Birkaç düşük öncelikli görev / hata çözülebildiğinden, ekip için bir bütün olarak da faydalıdır. Yeni insanlara yardım eden kişi, kendilerine atanan görevlerle uğraşmak için daha fazla zamana sahiptir, çünkü sürekli el tutma gerekli değildir ve yeni kişinin karşılaşabileceği sorunlarla / sorunlarla başa çıkmak için zaman planlanabilir.

İlk işe alımlar üzerinde çalışmak için küçük ama çok küçük ve iyi tanımlanmamış bir göreve ihtiyaç duyulur. Bu şekilde, görevlerini nasıl gerçekleştireceklerini anlamaya çalışarak kodun nasıl yapılandırıldığını anlamaya başlayabilirler. Süreçte sorular ortaya çıkacak ve bu noktada bunları kod tabanını içselleştirmelerine yardımcı olmak için kullanabilecekleri belgelere veya diğer kaynaklara yönlendirebilirsiniz. Ayrıca, geliştirme, taahhüt etme, uygulama döngünüzün kısa olması ve emeklerinin meyvelerini mümkün olan en kısa sürede görebilmeleri için yardımcı olur.

İşte böyle giderim

1. Onlara projeyle ilgili bazı görevler verin. (Örneğin: Projeniz veritabanı uygulamasıysa, sadece veritabanına bağlanmak ve basit bir işlem gerçekleştirmek için bir uygulama oluşturmasını isteyin.)
2. Çalışma fikrini anladıklarını gördüklerinde, onlara Projenin bir demosunu verin
3. Onlardan belgeleri okumalarını isteyin.
4. Kodlama stillerini ve standartlarını tanıyın
5. Daha sonra onlara bazı hata ayıklama egzersizleri yapın (projenin akışını bilmek için).
6. Onlardan önceden düzelttiğiniz bir noktayı düzeltmelerini isteyin (sadece mantıklarını bulmak için).
7. Sonunda onları projenin bir parçası haline getirin.

Unutmayın: ne kadar denerseniz deneyin, katılımcılar projeyi tam olarak anlamayana kadar ve ondan en verimli şekilde iş yapamayacaksınız.

Birincisi - öncelikle kullanıcının bakış açısından hangi sorunları çözdüğünü keşfetmek için yazılımı nasıl kullanacağınızı öğrenin. Bir kullanıcı arayüzü yoksa (örn. Bir arka uç hizmeti veya başka bir şey), tüketmek için mevcut olan herhangi bir arayüzü kullanmasına izin verin. Bir kullanıcının yazılımınız hakkındaki görüşüne yeni bir bakış atmak her zaman iyidir ve projeye zaten gömülü olduğunuz için yeni çalışanın yapamayacağınız şeyleri görmesine yardımcı olabilir.

Bundan sonra, iyi bir ilk proje, yazılıma eklenecek eklenti veya yeni bir modül gibi bir şey olabilir ve mevcut kod tabanının ihtiyaç duyduğu bilgi miktarını en aza indirir. Yeni bir şeyler yazmak her zaman birçok kaynak dosyada birçok değişiklik gerektirebilecek bir hata düzeltmesi yapmaktan daha kolay olacaktır. Bence, yeni bir çalışana bir hata düzeltme görevi vermek muhtemelen onları şirketinizi kapatacaktır.

Yenilerini projeye alıştırmak için ana hatlarınız makul görünüyor. Ancak başlangıçta öğrenecek çok şeyleri olacağını unutmayın. Bu genellikle ezici bir durumdur. Sabırlı olmanız ve aynı soruları tekrar tekrar cevaplamanız gerekir. Bu normaldir, yeni geliştiriciler çok şey öğrenmek zorundadır, bunu hafife almayın. Bu tekrarlanan sorular hakkında öfkelenirseniz, en iyi ihtimalle çok yavaş ama çoğu zaman imkansız olan şeyleri tek başına sormayacaklarını ve bulmayacaklarını düşüneceksiniz. Ayrıca lingo öğrenmek zorunda kalacaklar. Çoğu takım projesi kendi dilini geliştirir. Bilinçli olarak açıklarken lingodan kaçınmaya çalışın. Bunu annenize açıklayacağınız gibi açıklayın. Yine sabırlı olun.

Buna ek olarak, bazı değerlendirme merkezi tarzı görevleri deneyerek bunları zaten ekipte bulunan diğerleriyle entegre etmeye çalışabilirsiniz, örneğin, bir kahve fincanı destekleyen 4 yaprak kağıttan 45 dakika içinde bir köprü inşa edin. Bu tekniği yazılım mühendisliğinde pratik bir derste, 8 öğrenciden oluşan bir grubun 3 hafta boyunca tek bir proje üzerinde çalışmadan önce buzları kırmasını sağlamak için kullanıyoruz. Aşama oluşturma ekibini hızlandırmaya yardımcı olur.

1) Onlara kod kurallarınız ve yönergeleriniz hakkında bir açıklama verin. Ayrıca uygulamanızın nasıl çalıştığına ve genel kod yapısına ilişkin genel bir açıklama da yapın.

2) Diğer kodlardan büyük ölçüde bağımsız olan bazı küçük hataları veya projeleri bulun. Ne yapılması gerektiğini, kodun neresinde olduğunu açıklayın ve düzenli olarak kontrol edin.

3) Daha az ve daha az kontrol ederken yavaş yavaş daha büyük ve daha büyük projeler vermeye başlayın.

4) Zaman zaman yanlarında oturun. Bir başkasının bir problemle nasıl başa çıkacağına bakarak çok şey öğrenebilirsiniz. "Oh, ctrl- 'ye basarak kodunuzdaki işlevleri arayabilirsiniz." çok faydalıdır.

Şimdi, iki uç nokta olduğunu gördüm :

• Her beş dakikada bir soru soran biri. Msgstr "Bu Path.Join ne yapıyor?". Bir yanıt için önce Google’ı almalı ve yalnızca bir cevap bulamadıklarında size gelmelidirler.

• Ve diğer uç nokta, tek bir soru sormadan yarım gün çalışan biri. Soru sormanın iyi bir şey olduğunu düşünmelidirler. Sadece önce kendileri denemelerini istiyorum.

Bunlar benim formülümdü ve birkaç yeni gelenle birlikte kullanıldı - bu adımların oldukça etkili olduğu kanıtlandı.

a) Tüm yeni geliştiricilere 2 gün boyunca proje gereksinimleri ve geliştirme süreçleri hakkında bazı bilgiler verilecektir.

b) Yeterli kapsamı olmayan kod için 3 haftalık Junit testi yazma görevi atama.

c) 3 yapıldıktan sonra küçük görevler atayın

d) Karmaşık görevler atayın ve bitti.

Bence sadece bazı küçük görevler atayın, birkaç birim test yazmalarını isteyin, bazı regresyon başarısızlıkları hatalarını ayıklayın. Çok büyük veya talepkar bir şey yok, ama onları ayaklarının üstünde tutacak kadar.

Ayrıca, tercihen adayın mentörlüğüne yardımcı olabilecek yeni bir geliştirici başına kıdemli bir geliştirici atamalısınız.

Ve evet, sistem hakkında ne öğrendiklerini belgelemelerini sağlayın. Burada bir çeşit dahili wiki sayfanız olduğunu varsayıyorum. Değilse, hem uzun hem de kısa vadede kesinlikle bir zorunluluktur - insanların rampa yapmasını şaşırtıcı derecede hızlı bir şekilde. Wiki sayfaları yalnızca kod belgelerini değil, aynı zamanda bilinen sınırlamalar (bu yazılım: D), geçici çözümler, zaman / bellek performansı metrikleri vb.

Sadece iyi kodlama uygulamalarını ve standartlarını değil, okunan kodun nasıl yapılandırıldığını açıklayın. Yazılımın ne yapması gerektiğini ve bunun nasıl elde edileceğini veya nasıl elde edileceğini açıklayın.

Yapacakları bir iş olana kadar anlamayacaklar, bu yüzden gerçek işe başlamadan önce iki bölüme ve çalışmaya başladıktan sonra ikinci bölüme ayrılmayı öneririm. Bazı kodlara veya belgelere bakacaklar ve " WTF !? " diye düşünecekler . Bu meydana geldiğinde, birisi onlara eşlik edecek ve küçük ayrıntıları açıklayacaktır.