Farklı beceri seviyelerine sahip bir takımı nasıl yönetmeliyim?


16

Bazı arkadaşlarımla bir yazılım projesi üzerinde çalışacağım ve teknik lider olarak atandım. Bu adamların hiçbiri kötü bir programcı değil, ama onlardan önemli ölçüde daha fazla tecrübem var. Çalışmayı ekipteki herkes arasında dağıtabilmem gerekirken aynı zamanda birbirimizin ayak parmaklarına basmadığımızdan da emin olmalıyım; taahhüt ettikleri her şeyi gözden geçirmemi gerektirmeden, bu projeyi başarılı kılmak için ihtiyaç duyduğumuz nispeten yüksek kalite ve ölçeklenebilirlik standartlarını karşıladıklarını.

Mikro yönetimden kaçınırken standartları nasıl korumalıyım? Bazı diyagramlar yapmak, bazı kod incelemelerini planlamak ve bozabilecekleri herhangi bir şeyi düzeltebileceğime güvenmek için yeterli mi, yoksa TDD yoluna gidip ekibin tatmin etmesi için açık testler yazmalı mıyım?


11
Aynı beceri seviyelerine sahip bir ekip var mı?
P.Brian.Mackey

@ P.Brian.Mackey: Yani oldukça farklı.
Jon Purdy

@Jon: Umarım kendinizi ne içine soktuğunuzu bilirsiniz. Onlar-si olmak anlaşma içinde bazı "domuz" emin olun (!). Görünüşe göre, birim testleri bile yazamıyorlarsa ve (!) Bunu kendi başlarına nasıl yapacaklarını keşfetmediyse, orada sizinle çok fazla deneyime sahip birine ihtiyaç duyduğunuz belirsiz hissi alıyorum: belki de onların yeteneklerini abartıldığını düşünmem için. Söylemeye gerek yok, durumdan daha fazla yetkinlik varsaymak iyi bir proje yönetimi tekniği değildir.
Henrik

@Henrik: Kendimi ne içine soktuğumu biliyorum, diğer geliştiricileri yönetme konusunda çok fazla deneyimim yok ve işlerin sorunsuz geçmesini sağlamak için biraz tavsiye almak istiyorum. Yeteneklerine tam güven duyuyorum ve bence insanlar soruma oraya koyduğumdan çok daha fazla olumsuzluk okuyorlar. Hayatımın yarısından biraz daha fazlasını programlamaya başladım, bu yüzden 2-3 yıllık deneyime sahip bu adamların henüz karşılaşmadıkları birçok hata yaptım.
Jon Purdy

Bir şirket veya yan proje için mi?
Marcie

Yanıtlar:


10

Bazı kodlarını gözden geçirmeli ve birbirlerini incelemelerine izin vermelisiniz. Check In Police olmak istemezsiniz, ancak mümkün olduğunca sık geri bildirim vermek istersiniz. Gözden geçiren olmak anlayışlarını pekiştirebilir. Kodunuzu da incelemelerine izin verin. Model olun.

Yan Not: Yıllık inceleme sırasında sürpriz olmamalıdır.


2
+1 "Model olun." Kod incelemelerinde gördüğüm en büyük fayda bu oldu: başkalarının kayganlığından öğrenmek. Bu ve ara sıra kusuru yakalamak.
Peter K.

1
"Araf " ken
Henrik

9

Her şeyden önce : beklentilerinizi iletin ve mümkün olduğunca farklı şekillerde tasarım yapın. Diyagramlar bazıları için iyidir; tanımlı arayüzler başkaları için çalışır; çift ​​programlama da çalışır; resmi kod incelemeleri de bazı insanlara yardımcı olabilir.

Ben de mümkün olduğunca otomasyon kullanılarak tavsiye:

  • .Net bölgesinde iseniz , ekibin NDepend veya Resharper gibi bir aracı kullanmasını sağlayın . Sevmiyorsanız standart kuralları düzenleyin.
  • Testinizi mümkün olduğunca otomatikleştirin.

İyi kurulmuş olmaları koşuluyla, başarısız bir test durumu veya otomatik denetim aracıyla tartışmak zordur.


3
Kötü programcılar muhtemelen kötü test senaryoları oluşturuyor mu?
JeffO

1
Resharper gibi araçlar def. temiz, ama kesinlikle ücretsiz değil. Otomatik test, beceri düzeyleri çok düşükse pratik olmayan bir gereksinim belirleyebilen test edilebilir kod yazmayı gerektirir.
P.Brian.Mackey

@Jeff: Kötü programcılar değiller, sadece farklı geçmişlere sahibiz ve onlarla ilgili yıllarca var. Muhtemelen ben ve en deneyimli adam varsa testleri yazacağız.
Jon Purdy

@ Jeff O: O zaman onları takımdan çıkar.
Peter K.

@ P.Brian.Mackey: Soruda ücretsiz araçların özellikleri yoktu. Kod test edilemiyorsa, bunları ekipten çıkarın. Onlara test edilebilir kodun nasıl yazılacağını göstermeye çalışın ve herhangi bir iyileştirme yapmazlarsa, bunları takımdan çıkarın.
Peter K.

5

Aynı projede gerçekten çok çeşitli beceri seviyeleri ile çalışıyorsanız, bazı problemler olacaktır. Soru, onlarla ne zaman başa çıkacağınızdır. Yardımlarını almamaktan daha iyi olabileceğiniz kötü kod yazacaklar mı? Bu kişisel gerginlik yaratacak mı? Arkadaşlıkları bitirecek misin? Bu sorular sizden başka hiç kimsenin cevaplayamayacağı.

Herkesin ekipte kalacağını varsayarsak, ödevleri küçük parçalara ayırmanızı (daha büyük olanlar daha yetenekli adamlara gider) ve işiniz bittiğinde en yetenekli geliştiricilerin yeniden canlanmasını öneriyorum. KG'yi sıkı, düzenli aralıklarla çalıştırdığınızdan emin olun. Bu zaten gerçekte olanlara oldukça yakın.


3

Mümkün olduğunca yabani otlardan uzak durun. Herhangi bir takımda liderseniz, krizler ve büyük resim için bant genişliğinizin belirli bir bölümünü kaydetmeniz gerekir. Diyagramlar iyi ve kodlama standartları her zaman aklı başındadır, ancak insanların birbirlerinin işlerini kontrol ettikleri süreçleri ayarlamak daha da iyidir (çapraz test, akran incelemeleri, çift programlama). Takımdaki herkesin bir yıldız olması gerekmez - ekip birlikte genellikle bireylerdeki zayıflıkların üstesinden gelebilir.

Tavsiye ettiğim şey, insanlara kodlamalarında hangi hataları gördüğünüzü söyleme dürtüsüne direnmenizdir - bunun yerine onları kendileri görmeye yönlendirin. Geliştirme çalışmalarının ortak incelemesinin bir parçası olarak kalın, ancak diğer üyelerden daha fazla katkıda bulunmadığınızdan emin olun. Bunun yerine, insanları gördüklerinizi görmeye teşvik etmek için ekstra çaba sarf edin ve gördüğünüz şeylerin neden önemli olduğuna dair bolca açıklama yapın.

Çakışma hakkında çok fazla endişelenmeyin - mantıklı bir iş kırılmasının ötesinde, ekip üyelerinden kendi aralarında check-in yapmalarını isteyebilir ve daha sonra iletişimin gerçekleştiğini doğrulayabilirsiniz. Ekip hızlı bir şekilde birbirlerine fikir birliği sağlamanın bir yolu olarak bakmaya başlayacak ve bu da işinizi yaklaşık 20 kat daha kolay hale getirecektir - o zaman yapmanız gereken tek şey büyük alanlar katılmadığında kravat kırıcı olmaktır.

Ardından takıma toplu olarak bakma çabalarınızı kaydedin. Her insanın müthiş güçlü yanları ve büyüleyici zayıflıkları olacaktır. İdeal olarak, zayıf yönlerine takımın verimliliğini devre dışı bırakmayacak şekilde çalışma şansı verirken, güçlü yanlarına uyan insanlara iş atmaya başlayacaksınız.

Takım liderliğinin nihai altın yıldızı, insanları zayıflıklarından haberdar edecek ve onları düzeltmeye başlayacak kadar motive ve iyi bilgilendirilecek şekilde yapıyor.


2

Oturup ekipteki herkesin hemfikir olduğu teknolojiler ve araç setleri hakkında tartışın. Bazı insanlar üzerinde anlaşmaya varılan araçlarda, takımdaki diğer araçlardan daha deneyimli olabilir, bu nedenle daha deneyimli olanların deneyim ve bilgiyi geri kalanıyla paylaşmaya istekli ve istekli olmaları gerekir.

Standartları tartışın, kabul edin, yazın, modelleyin ve iletin (adlandırma kuralları, en iyi kodlama uygulamaları ve klasör yapıları gibi).

Sürekli ve düzenli testler ve KG kontrolü yapın. Tutarsızlıklar gördüğünüzde kişiyi en kısa sürede bilgilendirin.


2

'Ekipte en deneyimli kişiyi organize etmesini sağla' diyecektim, ama o kişi gibisin.

Yapabiliyorsanız, projeyi iki seviyeye bölün. Uygulama katmanı / sürücü katmanı iyi bir ayrımdır. Ekibinizde iki alt grup oluşturun ve bu düzeyden her birinden bir kişi sorumlu tutun . Bu son derece iyi çalışabilir.

Kendinizi istifa edin. Taahhüt ettikleri her şeyi, özellikle erken gözden geçirmeniz gerekecek. Eğer her şey yüzmeye giderse sadece kodu göze çarparsınız. İnceleme sizi bu kadar zaman almayacak ve işlerin iyi gittiğine dair çok fazla güven verecektir. Büyük olasılıkla birisinin semaforları yanlış kullandığını veya kendi kütüphane fonksiyonunun veya böyle bir deliliğin kendi versiyonunu yazdığını göreceksiniz. Benim deneyimim, tomurcuktaki kod problemlerini silmek için yazılırken kodu izlemeniz gerekiyor.


Kod inceleme kısmında anlaşın. Onları mümkün olduğunca erken yönlendirmelisiniz.

2

Şirketinizde teknik bir liderden normal olarak ne beklenir? Ben bir menajerim ve bu noktada birkaç kez ve bu hafta başlayarak tekrar yapmak üzereyim (20 yıl ve 4 yıllık deneyimli bir ekibe katılmak için yeni başlayanlar ve diğerleri işe).

Ben bir menajerim ve teknik bir lider olabilirim (son birkaç yılda, takım içinde liderliği büyütmek için ikinci rolü oynadım. Her durumda, bazı düşünceler:

  • Tüm ekibin becerilerini ve zayıflıklarını değerlendirin.
  • Bir büyüme planı oluşturun - Odak noktanız en zayıf üyeleri büyütürken, gerçekten herkesi birey olarak ve ekip olarak büyütmeye odaklanmalısınız.
  • Bu planı iletin ve herkesin beklentilerini belirleyin.
  • Öğrenme ve doğrulamayı ekip boyunca dağıtın. Siz, öncü olarak, işin aslan paylaşımı benim iken, işi dağıtmak, daha kıdemli ekip üyelerinize liderlere yardımcı olacaktır.
  • Düzenli bir geri bildirim döngüsü oluşturun. İlerlemeyi değerlendirmek ve geri bildirimde bulunmak için ekip üyeleriyle görüşün.
  • Başarıyı sağlamak için planı gerektiği gibi ayarlayın.
  • Birisi işe yaramıyorsa ve makul bir yardımla bile, onları dışarı itmeye hazır olun. Bu karmaşıktır, ancak bir plan, beklentiler belirlediyseniz ve bir geri bildirim döngüsü sağladıysanız, bunu yapmak için çok daha iyi bir konumda olacaksınız.
  • Takım moraline dikkat edin. Bu tür bir durum, bir takımı büyütmek veya parçalamak için harika şeyler yapabilir. Liderlik becerileriniz ve takıma yaptığınız yatırım sonucu belirlemek için çok yol kat edecektir.

1

Bir "Yazılım Mimarisi" tanımlamanın ne olduğuna bakmayı deneyin. Ayrı olarak geliştirilebilir modüller oluşturmak, ön tasarım ve analiz yapmanın ana nedenlerinden biridir. Bu tür bir iş yapmanın tarzının dışında olduğunu biliyorum, ancak daha yeni geliştirme yöntemlerinin benimsediği bazı vakaların aksine her durumda işe yarıyor.


1

Takımdaki en deneyimli geliştirici olarak ağır koçluğunuzdan beklerim .

Takımın kanban'ı kullanarak kendilerine iş atamasına izin verin ve ardından tüm gününüzü her biri ile çift ​​programlama yaparak geçirin.

Kötü bir alışkanlık ya da farkında olmaları gereken bir şey gördüğünüzde, her şeyi durdurun ve beyaz tahtaya çizin.

Birkaç hafta sonra ekibin genel becerileri size yaklaşacağından ağır koçluğu yavaşlatabileceksiniz.


1

Konumunuzdan incelemeye cazip geleceğim birkaç farklı liste var:

  1. Bu takımı ne kadar iyi tanıyorum. Takımdaki herkesin güçlü ve zayıf yanlarını biliyor musunuz? Her insandan en iyi şekilde nasıl yararlanacağınızı biliyor musunuz? Çalışmayı herkes için nispeten adil bir şekilde nasıl böleceğinizi biliyor musunuz? Bu tür sorular, bazı kişilerin görüşlerini değiştirebilecek bazı beceriler geliştirebileceğinden, bu listelerde zaman içinde değişimler olabileceğini soran ve anlayan bir şeydir. Atandığınızda ekipte bazılarının sizden beklentileri oldu mu? Bu son sorunun insanların dürüstçe cevap vermesini sağlamak zor olabilir, ancak bu, tartışılan şey için çok kişisel ise, suç veya kızgınlığı karıştırmadan anlamlı bir şekilde açıklanabilir ve tartışılabilirse çok yardımcı olabilir. insanlar. Bir grup toplantısında kişisel görüşler almaya çalışmayın,

  2. Kendimi ne kadar iyi tanıyorum. Burada bazı teknik otoriteleri talep etmek için geçmişinizden hangi unsurları kullanıyorsunuz? Takıma hangi güçlü ve zayıf yanları getiriyorsunuz? Siperlere düzenli olarak girmeniz bekleniyor mu? Onları yönlendirmek için bu takıma tanıtmak istediğinizi gördüğünüz uygulamalar var mı? Geçmiş deneyimlerden hatırladığınız ve bunlardan herhangi birinin ekibin yaptığı işte görünmeye başlayıp başlamadığını görmek için uyarı işaretleri var mı?

Bir bakıma bunların hepsi iletişime bağlı. İyi şanslar!


0

bazı teknik konuların düzenli (haftalık) sunumunu yapmalı ve grup etrafında dönmesini sağlayabilirsiniz. Bu şekilde herkes bir şeyler öğrenecek. Ve gençlerin de sunum yapmasına izin verin, bir şeyi gerçekten anlamanın onu öğretmekten daha iyi bir yolu yoktur. Konu seçmelerine yardımcı olabilirsiniz.

Bazılarının nasıl konuşulacağı konusunda koçluk yapmak herkes için uygun olabilir. Benim için bunu yapan üniversitede bir prof vardı ve çok yardımcı oldu.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.