Yeni kodla yeni bir takımı yönetmek için ipuçları / püf noktaları [kapalı]

Kendinizi en üst düzey geliştirici olduğunuz ve takımdaki diğer birçok kişinin birkaç yıl boyunca size göre yeni olduğu yeni bir takımda nasıl ele alıyorsunuz? Takımın önündeki görev, sizden başka hiç kimsenin kariyerinde daha önce başaramadığı bir şeydir.

Yönetim tüm ekibin daha yüksek verimliliğinde ısrar ediyor ve üst düzey geliştirici olarak siz sorumlusunuz.

Böyle bir durumda ortaya çıkmak için herhangi bir ipucu var mı? Açıkçası, tüm ekibin öğrenmek için zamana ihtiyacı var ve ekibin yenisini unutmayalım. Ancak, son teslim tarihleri ​​de yaklaştı ...

Sıkı bir süre veya projenin yeniliklerinin iyi mühendislik uygulamalarına müdahale etmesine izin vermeyin. Bir yazılım deposu oluşturun, bir kodlama stilini kabul edin, bir test takımı ile gelin, vb. sıkı çalışın ve önlerindeki görevi öğrenin.

Ya da başka bir şekilde söylemek gerekirse: Yönetim sizin sorumluluğunuzdadır, çünkü yönetim geçmişinizin ve deneyiminizin size kaliteli yazılım oluşturmak için gereken araçları verdiğine inanır. Bu görev şu anda göz korkutucu göründüğü için becerilerinizi aniden unutmayın.

İlk olarak, ilk kod satırından bir kaynak kodu kontrol sistemi kullanmaya başlayın . Kodu erken ve sık sık kontrol etme alışkanlığı edinin.

İkincisi, bir test stratejisine karar verin . Tabii ki bu birim testleri anlamına gelmelidir, ancak kabul testlerini nasıl otomatikleştireceğinizi de düşünmelisiniz.

Üçüncü olarak, kodunuzun düzenli olarak oluşturulması ve düzenli olarak test edilmesi için sürekli bir entegrasyon sunucusu oluşturun .

Bunu elde ettikten sonra, bir takım olarak bazı basit kodlama standartları belirleyin . Kodunuzun herkes tarafından kolayca okunmasını istiyorsunuz. Standartların ne olduğu gerçekten önemli değil. Sekmelerle girintili, boşluklu girintili, aynı satırda süslü ayraç. Ne oldukları önemli değil, sadece herkesin sürekli olarak uyguladığı.

Ekip çoğunlukla genç geliştiriciler olduğundan, sisteminize çok fazla teknik borç eklemediklerinden emin olmak için kodu sık sık gözden geçirmeyi planlayın .

Son olarak, SCRUM'u kullanmayı düşünün . Bunu yaparsanız, bir koç kiralayın veya bir eğitim alın. Hepiniz daha önce hiç yapmadığınız bir şey yaptığınızdan, gerçekçi son tarihler oluşturmak imkansızdır. SCRUM ile, yönetiminiz günlük olarak ne yaptığınıza ilişkin görünürlüğe sahip olur, böylece hangi ilerlemenin yapıldığını (veya yapılmadığını) görebilirler. Ve son teslim tarihleriniz size verildiği için, SCRUM en azından son teslim tarihini karşılayamıyorsanız, en azından tamamlanmış hikayeleri artımlı bir şekilde teslim ettiğinizi garanti eder, ki bu muhtemelen bir dev ile sona gelmekten daha iyidir hiç çalışmıyor.

@Chrisaycock'un cevabına ek olarak ... Mentorluk / eğitim vb. İçin ayırmanız gereken zamanı hafife almayın. Öncü olarak, detayı bırakmayı ve ekibinize güvenmeyi öğrenmeniz gerekecektir. İşiniz, kolaylaştırıcı, yol bloğu sökücü olmak ve yönetim oraya girdiğinde müdahale çalıştırmaktır. "Normal" bir ekipte, yaklaşık 7 veya 8'de, kurşun artık programlamaz, Sizin durumunuzda, bu 3'e düşer veya 4 (Belki daha da az), proje için bir programlama kaynağı değilsiniz.

İki alanda iletişime odaklanın.

Bunu yapmak kolay değil ve bu işin zor olmasının bir nedeni de bu. Son teslim tarihini karşılamak kesme özellikleri demekse, bunun üzerine gelin. Tüm bunlardan kaçınmaya çalıştığınız bir şey, bir son tarih yapmak için hızlı kod. Bu, uzun sürmeyecek bir kod tabanının sonunun başlangıcı ve boğulan teknik borcun başlangıcıdır.

2) Takımlar arası iletişim. Bryan ve diğerlerinin önerdiği gibi resmi uygulamalar oluşturun. Düzenli olarak bir ekip olarak, örneğin günlük scrumlara ek olarak haftada bir kez bir araya geldiğinizden emin olun . En önemli aracınız dinleyerek saygı ve güven kazanın . Yardıma odaklandığınızdan emin olun. Her ne pahasına olursa olsun olumsuz eleştiriden kaçının. Gerektiğinde olumlu eleştiri ve cesaret kullanın, örneğin "bu harika, düşünmek isteyebileceğiniz bir şey X" bitti ", ihtiyacımız olan şey bu değil, bunun yerine X yapmanız gerekir"

Yaptığım şey yetenekli olanları tanımlamak ve bölmek ve fethetmektir. İlk 2 veya 3'ü alıp kaptanlar yapıyorum. Diğerleri daha sonra kaptanları kendi küçük takımlarına kadar eşit olarak takımlara ayrılır.

Bir programa kaptan parçalarını veya modüllerini veriyorum.

Kaptanlar, yenilere daha küçük programlama veya araştırma görevleri verirken, kendilerine ne yaptıklarını açıklarlar, böylece mentörlük yaparken olur.

Odayı herkes aynı açık alanda olacak şekilde ayarlamaya çalışıyorum ama her takımın kendi bilgisayar dairesi var. Herkese uzaktan bağırmaktan hoşlanıyorum, bu yüzden işler hızla ilerliyor.

Bu, şimdiye kadar yaklaşık 10-20 programcı için iyi çalışıyor. Küçük gruplar bir grupta olmaktan daha iyidir ve henüz daha büyük bir şeyle çalışmadım.