Bir projedeki geliştiricileri döndürmek iyi veya kötü bir fikir midir?

Başka bir küçük ekiple birlikte büyük yeni bir projede çalışmaya başlayacak küçük bir ekip üzerinde çalışıyorum. Diğer takım şu anda yıllardır üzerinde çalıştıkları eski bir sistem üzerinde çalışıyor.

Yönetici, ekibimdeki geliştiricilerin, eski sistemde çalışan geliştiricilerin yerine birkaç ayda bir dönmeye karar verdiğini belirtti. Bu şekilde diğer takım yeni proje üzerinde çalışma ve yeni sistemi daha iyi anlama şansına sahip olacak.

Her 2-3 ayda bir geliştiricileri projeden döndürmenin yararlarını ve sakıncalarını (varsa) bilmek istiyorum.

Bunun "Lider geliştiriciyi döndürmek iyi veya kötü bir fikir mi?" İle benzer bir soru olduğunu biliyorum. , ama bu soru bir lider geliştirici üzerinde duruluyor. Bu soru tüm ekibi projeye açıp kapatmakla ilgili (yeni proje için teknik lider olabilir veya döndürülmeyebilir - henüz bilmiyorum).

Herkesin bunun iyi bir şey olduğunu düşünmesine şaşırdım. Peopleware (IMO, hala okumaya değer değerli birkaç yazılım proje yönetimi kitaplarından biri) yazarları kesinlikle katılmıyorum. Neredeyse kitabın IV. Bölümünün tamamı bu konuya adanmıştır.

Yazılım ekibi inanılmaz derecede önemli bir işlevsel birimdir. Takımların gerçekten üretken olabilmesi için jöle yapmaları gerekiyor. Ekip üyelerinin birbirlerinin saygısını kazanmaları, birbirlerinin alışkanlıklarını ve tuhaflıklarını, güçlü ve zayıf yönlerini öğrenmek zaman alır ( çok zaman alır).

Kesinlikle, kişisel deneyimimden, belirli insanlarla çalıştıktan bir yıl sonra, beni rahatsız eden bazı şeylerden gülmeyi öğrendim, takım lideri olarak tahminlerimin çok daha iyi olduğunu ve bunun çok zor olmadığını söyleyebilirim. Herkesi mutlu etmek için işleri dağıtın. Başlangıçta böyle değildi.

Şimdi diyebilirsiniz ki, "Ah, ama bütün takımı parçalamadık, sadece birkaç kişiyi hareket ettiriyoruz." Ama, (a) ne kadar körlemesine onların verimsiz düşünün değiştirmeler başında olacak ve (b) Eğer kendinizi bulacaksınız veya diğer takımların bile düşünmeden diyerek kaç kez "Gerçekten X sevdim" veya "Bu olurdu Y hala etrafta " , kolay ve bilinçsiz bir şekilde yeni üyelere saldırmak ve mevcut ekip içinde şemalar oluşturmak," eski "üyeler arasındaki hoşnutsuzluğu ekilmekle, daha kolaydı .

İnsanlar bunu bilerek yapmazlar elbette, ama neredeyse her zaman olur. İnsanlar düşünmeden yaparlar. Ve eğer kendilerini zorlamaması için zorlarlarsa, konuya daha fazla odaklanmaya başlarlar ve zorunlu sessizlikten korkarlar. Takımlar ve hatta alt takımlar, yapıyı bozduğunuzda kaybolan sinerjiler geliştirecektir. Peopleware yazarlar "teamicide" bir biçimidir diyoruz.

Olduğu söyleniyor, ekip üyelerini döndürmek korkunç bir uygulama olsa da , ekiplerin kendilerini döndürmek tamamen iyi. İyi çalışan yazılım şirketleri bazı ürün sahipliği kavramlarına sahip olsalar da, takım eski projeyi tamamladığı veya en azından getirdiği sürece, tüm takımı farklı bir projeye taşımak neredeyse bir takım için rahatsız edici değildir. mutlu oldukları bir seviye.

Sahip olarak takım yerine stints geliştirici stints, size bir birim olarak her takımda kötü yan etkilerden herhangi olmadan geliştiricilere (dokümantasyon, "çapraz tozlaşma", vs.) dönen ile almak için beklediğiniz tüm aynı avantajlar elde edeceksiniz. Yönetimi gerçekten anlamayanlara, daha az üretken görünebilir, ancak ekibi ikiye bölerek kaybedilen üretkenliğin, o takımı farklı bir projeye taşıyarak kaybedilen verimliliği tamamen ciddiye aldığından emin olabilirsiniz.

PS senin dipnot size teknoloji kurşun olabileceğini belirtmek tek kişi değil döndürülmesine. Bu, her iki takımı da mahvetmek için garanti edilir Teknik lider, yönetici değil liderdir, ekibin saygısını kazanmak zorundadır ve sadece üst düzey yönetim tarafından yetki verilmez. Bütün bir ekibi hiç birlikte çalışmadıkları ve mimarlık, kullanılabilirlik, kod organizasyonu, tahmin gibi şeyler hakkında farklı fikirlere sahip olma ihtimalinin yüksek olduğu yeni bir liderliğin altına sokmak cehennem gibi stresli olacak. Çünkü liderliği eski liderlik yokluğunda uyumunu yitirmeye başlayan ekip üyeleri için güvenilirlik ve verimsizlik yapmaya çalışmaktadır. Bazen şirketler varBunu yapmak için, örneğin kurşun vazgeçerse veya terfi ederse, ancak seçim yaparak yapmak delice gelir.

Burada kendimi bir dezavantajı göremiyorum. Rotasyon sizi alır:

• Kurumsal bilginin çapraz tozlaşması - herkes eski projeyi ve yenisini en azından teoride bilecek.
• Çapraz eğitim - farklı projeler sıklıkla farklı şeyler gerektirir. Güzel, temiz yeşil alan projelerinden daha çirkin, eski projelerde çalışan bir geliştirici olarak çok daha büyüyorsunuz.
• Temelde daha iyi projeler - belgelendirmenizi bitirmek ve birlikte yaşamak istediğiniz ancak halka açık olmayan çirkin işlemleri temizlemek için yeni bir ekibin gelmesi gibi bir şey yok.
• Daha iyi kod - çoğu durumda daha fazla kafa daha iyidir.
• Muhtemelen moral iyileştirmeleri - çeşitlilik hayatın baharatıdır. Kalıcı proje hata tespit / kanal bantlama modunda kalıcı olarak takılmak isteyen var. Ayrıca “yeni” projenizin bir noktada miras olacağını unutmayın, sonsuza dek orada sıkışıp kalmak ister misiniz?

Muhtemelen tek dezavantajı, anahtarlama yerlerinden aldığınız üretkenlik düşüşüdür, ancak ilk seferde sadece kötü sonuç vermelidir. Daha sonra her iki taraf da her iki yerde de bir süre oturacak ve devirmenin çirkin kısımları muhtemelen daha iyi anlaşılacak ve belki çözülecektir.

İlginç bir şekilde, deneyimlerime sık sık projelerimize bu niyetle başladık. Bu doğrultuda, yeni projedeki kısıtlamalar ve çapraz eğitimin çok pahalı olduğuna inandığımız için bu amaçla harekete geçemedik.

Ekip, şirket, müşteri ve yazılım olmak üzere her tarafın yararlı olacağına inanıyorum. 2/3 ay, ciddi bir olumsuz etki riskinin sınırlı olduğu konusunda yeterince uzun bir işaret gibi gözükse de, söz konusu alternatif projeye kendilerini ayırabilecekleri yer değiştirme noktası dışında, ilgili geliştiriciler için bir bağlam değişikliği yoktur.

Birkaç olası faydadan bahsedilmedi:

• Daha iyi proje yönetimi. Her iki proje için de proje yöneticileri kurultaysa, her iki proje için de geçiş dönemlerinin acı çekmemesi için sıkı çalışmak en iyisidir. Bu, sırayla (kurulumunuza bağlı olarak), PM'ler ve geliştirme ekipleri arasında daha sıkı bir işbirliği sağlayabilir.
• Daha iyi (proaktif) belgeler. Bir projeye girip girdiğinizi biliyorsanız, bu sadece projenin en iyi çıkarları, şirketler en iyi çıkarları, genel olarak en iyi uygulamaları değil, şimdi her geliştiricinin yaşamı zıplatırken daha kolay hale getirmek için kendi çıkarları ile ilgilidir. etrafında.
• Moral meselesi, eğer geliştiricileriniz eski bir projeye sıkışıp kalmadıysa, o zaman istediğiniz geliştiriciler olmayabilir! Eğer varsa, onları değiştirip diğer geliştiricilerin üzerinde çalışmasını sağlamak, şirketiniz için sevgi hissetmelerini sağlayacaktır - hiç kimsenin görmeyeceğini düşündükleri kod parçalarını düzeltebilirler. Eski sistemler genellikle kendi zararları için olan ikinci sınıf projeler olarak görülüyor, belki de bu algıyı değiştirmeye yardımcı oluyorsunuz.

Rotasyon, şirket için iyi bir şeydir ve geliştiriciler için de iyi bir şey olabilir.

Pek çok iyi sebep var ve Wyatt, cevabında çoğundan bahsetti.

Sizin durumunuzda, bunu tanıtırken, yeni projeyi eski projeye taşıyan geliştiricilerin mutlu olmadıklarını söyleyebiliriz, bu yüzden bunun neden olduğu ve bunun ne kadar sürdüğü konusunda çok net bir iletişimin olması gerekir. ve için plan ilerliyor.

Takımları toptan olarak değiştirmeye başlamamayı ve başlangıç ​​için 1 veya 2 deveyi döndürmemeyi düşünmek iyi olabilir, ancak bu bir kişiyi bir indirgeme için seçmeye benziyor gibi görünebilir (bazı insanlar görebilir).

Aaronaught ile aynı fikirde olursak, kaç kişinin sadece olumsuz taraf göremediğini görmek çok garip .. Çok az sayıda kötü düşünceler var, çok hızlı bir şekilde işaretleyebileceğinizi düşünüyor - kodun sahibi yok ve herkes her şeyden sorumluyken kalite için iyi değil . Geliştiriciler kaynak değildir (hatta yöneticiler tarafından çok sık aranırlar), insanlardır ve ekip için birbirlerini tanımak çok önemlidir, rotasyon orada biraz kaos yapar. Daha uzun bir süre boyunca bir projede çalışıyorsanız, uzman olursunuz (yalnızca etki alanında değil, aynı projede), çoğu sorunun nereden geldiğini, kim size en iyi yanıtları veya belki daha spesifik etki alanı bilgilerini vb. Alacağını bilirsiniz. Eğer yeniyseniz, tüm bu düşünceleri öğrenmeniz gerekecektir, bu yüzden ilerlemeyi yavaşlatır. Ancak elbette, kuruluşunuzdaki diğer uygulamaları bilmek de iyi diğer ekipler nasıl kurulup örgütleniyor. Projelerinizin bir şekilde ilişkili olması özellikle iyi bir şeydir, örneğin bir proje diğerinin girdisidir (doğrudan gerekli değil), bu nedenle büyük resmi daha iyi anlayacaktır. Ve tabii ki yayılma uzmanlığı iyidir (eğer bu bilgileri almak için zaman kazanırsanız).

Aaronaught'ın en üst cevabına katılıyorum ve bazı eklemelerim var.

• İnsanlar itilmekten hoşlanmıyorlar.
• Hiyerarşik bir iş ortamında, insanlara daha sonra tekrar onlardan alınacak sorumluluklar atanabilir. Bu sadece işin bir parçası olabilir. Bununla birlikte, bu daha sık gerçekleşirse, bu kişilerin kendilerine atanan her şeyden sorumlu olmaları daha az olasıdır.
• İlk nokta, insanların kendilerinin yaratmadığı şeylerin bakım çalışmaları için de geçerlidir. Diğer insanların karmaşasını temizlemek (ya da daha nötr biçimde formüle edilmiş: bitmemiş işler) çoğu insanı yaratmada özellikle motive edici değildir.
• "Bir programcı bir programcıdır, bir programcıdır, gerektiğinde projelere eklenecek anonim eklentilerdir" felsefesi, herhangi bir programcının takdir edilmesini veya kendisine verilen görevlere daha fazla önem vermesini sağlamamaktadır.

Kimseyi yeniden atamak için mükemmel bir zaman, yaptıklarından sıkılmaya başladıkları zamandır. Kazanacak bir şey yok, her şey kontrol altında, iş yapıldı. Bu durumlarda, genellikle öne çıkacak ve diğer fırsatları kendileri isteyeceklerdir.

Elbette gerçeklik inatçıdır ve sıklıkla başka seçenek yoktur, herhangi bir nedenden ötürü başka bir yere ihtiyaç duyulabilir. Bu mutlaka fena değil, bir insanı önemli hissettirebilir ve eğer kişi büyük bir problemi çözecekse, onun için kredi verilecektir.

Bilgiyi yaymak için etrafınızdakileri karıştırmak, ciroyu arttırma eğilimindedir. Bu şekilde bilgi yayılacak, ancak muhtemelen niyetinde olmayan şirketin dışına da yayılacak.

TL; DR Bir takım yap, ardından 2 projeyi destekleyen bir takım.

@Aaronaught yankılanması için, karıştırma ekiplerinin yeni uygulamalara, süreçlere vb. Uyum sağlamak için zaman alabileceği için sorunlu olabileceğini düşünüyorum. Bu, daha fazla soru, karışıklık ve bu kimliği telafi etmeye çalışmak için harcanan zamanla sonuçlanır.

Öte yandan, 2 takıma tek bir takımda katılmak ve 1 takım desteğine sahip olmak için ortak bir çaba varsa, takım çok büyük olmadığı sürece harika çalıştığını düşünüyorum. Birden fazla projeyi destekleyen çok sayıda ekibin parçası oldum. Teknolojide 2 proje ne kadar yakınsa, geçiş o kadar kolay olur. Tecrübelerime göre bir projeden diğerine geçmenin maliyeti, dilleri, müşteriyi / sunucuyu (özellikle GUI'yi), endüstriyi (tıbbi, web, oyun) veya diğer benzer çizgileri geçerken gelir. İşin püf noktası, farklı insanların projede faydalarını elde etmek için yeterince sık çalışmalarına sağlamaktır, ancak geçiş maliyetinin faydaları aştığı kadar sık ​​değildir.

O zaman bir projeye daha fazla insan edinmenin faydaları, maliyetler gibi oldukça iyi bilinmektedir.

Programcıların Dönmesi, şirket açısından ve geliştirici açısından iyi bir şeydir.

Şirket bakış açısından

1. Yönetim, belirli bir geliştiricinin çoklu görev yapıp yapamayacağını ve değişikliklere adapte edip edemeyeceğini, güçlülüğünü ve zayıflığını öğrenir.
2. Eğer bir geliştirici bir sebepten dolayı şirketten ayrılırsa, şirketin geleceği için zaten hazır yedekleri var.
3. Birçok insan üzerinde çalışacağından projenin performansını artıracak, aynı şey gittikçe daha fazla geliştirici tarafından test edilecektir. (Test kaynağı israfı en aza indirildi)
4. Tüm ekip üyeleri takım içinde çalışır ve proje performansını artıracak ve gelecekteki yönetimde zor modül veya görevi uygularken ne tür bir takım yapılması gerektiğini öğreneceklerdir.

Geliştirici perspektifinden

1. Güven arttıkça geliştiriciyi daha olumlu hale getirecek.
2. Geliştiriciler, diğer takım arkadaşları kodundan daha iyi ve daha iyi fikirler alır ve bu tekniği gelecekteki gelişimde kullanabilirler.
3. Diğer takım üyelerinden daha iyi fikir ve öneri alındığında geliştiricinin verimliliği artar.

Sadece bir ana şey, akılda tutulması gereken,

Programcıların Dönmesi çok sık olmamalıdır. % 60 -% 70 gelişimden sonra, sadece kayma faydalı olacaktır.