Kod kalitesini kaybetmeden geliştirme ekibinizi harici mühendislerle ölçeklendirme

Giriş

Önemli noktalar

1. Yol haritanız çekirdek ekibiniz için çok dolu olduğunda dışardan mühendisler kullanın.
2. Onlar katılmadan önce basit kalite koruyucuları ve temel bir teslimat süreci belirleyin.
3. Dışarıdan gelen geliştiricileri, net bir kontrol listesi ve bir danışman arkadaşla işe alın.
4. Tüm mühendisler için tek bir ortak kurallar, incelemeler ve ölçütler seti uygulayın.
5. Büyüyen karma ekibin uyumunu sağlamak için kısa yazılı güncellemelere güvenin.

Neden geliştirme ekibinizi dışardan mühendislerle genişletmelisiniz?

Yol haritanız dolu ve kendi çalışanlarınız sağlıklı bir şekilde ayak uyduramıyorsa, geliştirme ekibinizi dışardan mühendislerle genişletmelisiniz. Ana fikir basit: dışardan mühendisler, kalite çıtanızı düşürmeden hız ve beceri katmalıdır. Eğer bakımının güvenli olduğu hissi veren istikrarlı bir iş ortaya koymanıza yardımcı oluyorlarsa, bu düzen mantıklıdır. Eğer sadece stres ve rastgele değişiklikler getiriyorlarsa, zamanlama yanlış demektir.

Ürün şirketlerindeki birçok lider aynı baskıyı hisseder. İş yükü artar, teslim tarihleri gecikir ve şehrinizde yetenekli mühendisleri işe almak uzun zaman alır. O anda, dışarıdan yardım alarak mühendislik ekibinizi genişletmeyi düşünmeye başlarsınız. Başka bir bölgedeki dış kaynaklı geliştirme ekibine veya zaman diliminize daha yakın olan daha küçük bir gruba bakabilirsiniz. Asıl soru, dışardan yardım alıp alamayacağınız değil, bunun yol haritanızı destekleyeceği ve daha derin sorunları gizlemeyeceği zamandır.

Dışarıdan mühendisleri davet etmenin bir nedeni, şu anda şirket içinde sahip olmadığınız becerilere erişim sağlamaktır. Veri, mobil uygulamalar veya yeni bulut kurulumları gibi alanlarda kısa vadeli desteğe ihtiyacınız olabilir. Her yeni konu için tamamen yeni bir ekip kurmak istemeyebilirsiniz. Bu durumda, yazılım geliştirme ekibinin genişletilmesi, çekirdek grubunuzun etrafında esnek bir destek katmanı sağlayabilir. Temel bilgi ve yönlendirmeyi şirketinizin içinde tutar ve net ve odaklanmış işler için dışardan yardım alırsınız. Günlük hayatta bu, ikinci bir şirket kurmaktan çok, yoğun bir ekibe sakin bir uzman eklemek gibi hissettirir.

Ayrıca çok temel bir zaman ve maliyet açısı da vardır. Güçlü kişileri kendi başınıza işe almak haftalar hatta aylar sürebilir ve bu süre zarfında iş yükünüz azalmaz. Burada, personel takviyesinin avantajlarını açıkça görebilirsiniz. Uzun vadeli işe alımları düşünmeye devam ederken, belirli bir süre ve kapsam için ekstra personel getirebilirsiniz. Bazı ekipler için bu seçenek, sabit personel sayısında büyük bir artışa neden olmak yerine, talep artışlarını dengeler. Bu tür bir yapı, tüm yapınızı kalıcı olarak değiştirmeden önce, ekstra kapasitenin ürününüz için ne gibi faydalar sağladığını test etmenizi sağlar.

Bu kişilerin ekibinize nasıl katılacağı konusunda farklı modeller de seçebilirsiniz. Personel artırımı modelinde, kendi ekibinize dışarıdan mühendisler ekler ve liderleriniz her gün onların çalışmalarını yönlendirir. Yakın kıyı geliştirme ekibi yapısında, çalışanlar yakın bir saat diliminde bulunur ve normal saatlerde görüşmelerinize ve sohbetlerinize katılabilir. Birçok şirket, yakın kıyı yazılım geliştirmeyi zaten bilen ve iç ekiplerle uyum sağlayabilen deneyimli bir yazılım geliştirme ortağıyla çalışır. Kültür, saat dilimi ve araçlar ne kadar yakınsa, sözleşmeler farklı olsa bile birçok kişinin tek bir ekip gibi hissetmesi o kadar kolay olur. Bu ortak temel, dışardan gelen çalışmayı kırılgan değil, doğal hissettirir.

Harici bir geliştirme ekibi eklemeden önce kod tabanınızı ve süreçlerinizi nasıl hazırlarsınız?

Ürününüzü nasıl geliştireceğiniz ve sunacağınız konusunda açık ve basit bir temel oluşturarak harici geliştirme ekibine hazırlanırsınız. Yeni kişiler gelmeden önce ortak kurallar, temel araçlar ve görünür bir çalışma şekli gerekir. Bu temel olmadan, her değişiklik kişisel stile ve hafızaya bağlı olur ve yeni kişiler doğru yolu tahmin edemez. Bu temel ile, yeni gelenler bile güvenli ve istikrarlı bir ritimle ilerleyebilir.

Bu temeli, kod için kalite koruyucu bariyerler olarak düşünebilirsiniz. Bu koruyucu bariyerler, kim yazmış olursa olsun, her değişikliğin geçmesi gereken basit kontrollerden oluşur. Bunlar, nesnelere nasıl isim verdiğinizi, dosyaları nasıl biçimlendirdiğinizi ve herhangi bir küçük iş parçası için "bitmiş"in ne anlama geldiğini kapsayabilir. Koruyucu bariyerler herkes için aynı kaldığında, ekip büyüdükçe ve değiştikçe ürününüz istikrarlı kalır. Bu, sadece tanıdığınız kişilere değil, tüm akışa güvenmeyi kolaylaştırır.

Ayrıca temel bir sürekli entegrasyon ve teslimat boru hattına da ihtiyacınız vardır. Bu uzun ifade, basit bir fikri tanımlar. Birisi kodu her değiştirdiğinde, sistem kontroller yapar ve bu değişikliği küçük, güvenli adımlarla kullanıcılara ulaştırmaya yardımcı olur. Bu boru hattı, ortak platformlarda bulunabilir ve ana kod deponuza her gönderimde çalıştırılabilir. Çalışan bir boru hattı, birçok küçük düzenlemeyi büyük, korkutucu sürümler yığını yerine temiz bir ilerleme çizgisine dönüştürür. Yeni çalışanlar bu yolu bir kez öğrendikten sonra, ekstra tahminlerde bulunmadan onu takip edebilirler.

Testler bu yolun önemli bir parçasıdır. CI/CD'de otomatik test, birisi yeni bir kod paylaştığında testlerinizin kendi kendine çalışması anlamına gelir. Ürününüzde en çok kullanılan yolları kapsayan basit kontrollerle başlayabilirsiniz. Zamanla, hataların nerede ortaya çıktığını gördükçe daha fazla test ekleyebilirsiniz. Küçük bir dizi istikrarlı test bile, kimsenin zamanında çalıştırmadığı devasa bir manuel kontrol listesinden daha fazla güvenlik sağlar. Bu yaklaşım, işleri gerçekçi tutar ve hem iç hem de dış mühendisleri destekler.

Ayrıca, başkalarından sisteminizin eski kısımlarına dokunmalarını istemeden önce bu kısımları incelemenize de yardımcı olur. İşte burada temel teknik borç yönetimi devreye girer. Teknik borç, çalışan ancak risk almadan değiştirilmesi zor olan kodu tanımlamak için kullanılan bir terimdir. Yeni çalışanlar için güvenli olan alanları ve en deneyimli personelinizin hala ilgilenmesi gereken alanları işaretleyebilirsiniz. Riskli kısımların nerede olduğunu bildiğinizde, harici geliştirme ekibini önce daha güvenli alanlara yönlendirebilirsiniz. Bu, ürününüzü korur ve yeni çalışanları gizli tuzaklardan uzak tutar.

Temelinin son kısmı basit güvenlik ve erişimdir. Güvenli bir yazılım geliştirme yaşam döngüsü kulağa ağır gelebilir, ancak açık adımlara dayanır. Kişilere yalnızca ihtiyaç duydukları erişimi verirsiniz, gerçek kullanıcı verilerini güvende tutarsınız ve gizli anahtarları özenle kullanırsınız. Ayrıca, küçük ölçekte bile olsa bir sorun olduğunda ne yapılacağını yazarsınız. Güvenlik normal işin bir parçası olduğunda, dış mühendisler yeni endişeler yaratmadan sürecinize katılabilir. Hukuk ve güvenlik ekipleriniz de bu büyümenin hızlı bir çözüm değil, bir planın sonucu olduğunu görür.

Harici geliştiriciler için güvenli bir işe alım planı nasıl olmalıdır?

Harici geliştiriciler için güvenli bir işe alım planı, onlara bağlam, araçlar ve net ilk adımlar sunar ve onları derin sulara atmaz. Her günün basit ve gerçek bir amacı olan rehberli bir yol gibi hissettirmelidir. Plan net olduğunda, yeni çalışanlar aylar değil haftalar içinde değer katabilir ve kendi ekibiniz sürekli sorularla yorulmaz.

Dışarıdan gelen geliştiricilerin işe alımı, önce öğrenmeleri gerekenler konusunda ortak bir görüşle başlar. Buna ürününüz, kullanıcılarınız ve normal çalışma şekliniz dahildir. Geliştiriciler için bir işe alım kontrol listesi, tüm bu öğeleri tek bir yerde toplayabilir. Her iki tarafın da açıp düzenleyebileceği basit bir belge şeklinde olabilir. Görünür bir kontrol listesi, "Sanırım bunu onlara zaten söyledik" ifadesini "Neyin yapıldığını ve sırada ne olduğunu tam olarak biliyoruz" ifadesine dönüştürür. Bu küçük değişiklik, herkes için sessizce yaşanan birçok stresi ortadan kaldırır.

İşte, bu tür bir kontrol listesinin temeli olarak sıklıkla işe yarayan basit bir liste:

1. Kod, iş takipçisi ve ana sohbet odalarına erişim.
2. Ürünü bir dizüstü bilgisayarda veya test sunucusunda çalıştırmak için gerekli adımlar.
3. Kullanıcılar, ana akışlar ve temel iş kuralları hakkında kısa bir kılavuz.
4. Ürün, kod ve araçlar hakkında bilgi alabileceğiniz kişilerin isimleri.
5. İlk gerçek değişiklik için hazır olan iki veya üç küçük, net görev.

Ayrıca, net bir irtibat kişisi belirlemek de yardımcı olur. Bir teknik lider veya kıdemli mühendis, ilk haftalarda oryantasyon arkadaşı olarak görev yapabilir. Bu kişi, tüm erken değişiklikleri gözden geçirebilir, soruları yanıtlayabilir ve geçmişteki seçimlerin neden böyle olduğunu açıklayabilir. Kısa günlük kontroller, hatta sohbette beş dakikalık görüşmeler bile işleri yolunda tutabilir. Sakin bir arkadaş ve istikrarlı temas noktaları, ilk günkü büyük konuşmalardan daha fazla güvenli oryantasyona katkıda bulunur. Zamanla, kısa yazılı notlar gibi daha fazla güncellemeyi geliştirme ekipleri için asenkron iletişime taşıyabilirsiniz.

Gördüğüm kadarıyla, oryantasyon sürecindeki en büyük risk sessiz bir kafa karışıklığıdır. Yeni çalışanlar çok fazla soru sorma korkusu yaşarken, eski ekip üyeleri her şeyin kendiliğinden "yerine oturacağını" umar. Dışarıdan gelen geliştiricilerin işe alımına yönelik net bir plan ve bu planın tek bir sorumlusu bu durumu değiştirir. Bir kişi bu sürecin sorumluluğunu üstlendiğinde, kalıpları tespit edebilir, zayıf noktaları düzeltebilir ve sonraki işe alım süreçlerini daha sorunsuz hale getirebilirsiniz. Birkaç ay içinde, bu plan her yeni çalışan eklediğinizde karşılaştığınız yeni bir zorluk olmaktan çıkıp tekrarlanabilir bir varlık haline gelir.

Dışarıdan gelen geliştiricileri yönettiğinizde, karma bir geliştirme ekibinde kod kalitesini nasıl korursunuz?

Karışık bir geliştirme ekibinde kod kalitesini, herkes için aynı basit kuralları, kontrolleri ve sayıları kullanarak korursunuz. Ürünün temiz ve güvenli bir sistem gibi hissedilmesini istiyorsanız, standartlarınız tüm mühendislere uygulanmalıdır. Kuralları sözleşme türüne göre ayırdığınızda, ekibinizdeki güven ve netliği de ayırmış olursunuz.

Karışık bir geliştirme ekibi, şirket içi ve dış mühendislerin aynı ürün üzerinde çalıştığı bir gruptur. Farklı yerlerde çalışıyor olabilirler, ancak tek bir birikim ve tek bir kod deposunu paylaşırlar. Bu karışım, derin alan bilgisi ile yeni bakış açılarını bir araya getirdiği için çok güçlü olabilir. Ancak her grup kendi alışkanlıklarını takip ederse kırılgan da olabilir. Net bir rehberlik olmadan, bu karışım farklı hissettiren ve arasında geçiş yapmak zor olan kod kümelerine dönüşür. İşte o anda kalite ve hız düşmeye başlar.

Basit kod inceleme en iyi uygulamaları bu konuda yardımcı olur. Her değişiklik, kim yapmış olursa olsun, en az bir kişi tarafından incelenmelidir. İncelemeler sadece stili değil, netliği, güvenliği ve sistemin geri kalanıyla uyumu da dikkate almalıdır. Bunu, kodu yaygın sorunlar açısından tarayan hafif araçlarla destekleyebilirsiniz. Bu rutinler, dış geliştiricilerin kod kalitesini, sakin ve tekrarlanabilir bir şekilde ekibinizin geri kalanıyla aynı seviyede tutar. İnsanlar birbirlerinden öğrenir ve "iyi"nin ne olduğu konusunda ortak bir anlayış geliştirir.

Ayrıca, yazılım geliştirme ekibinin küçük bir dizi ölçütünü de takip edebilirsiniz. Bunlar, bir işin tamamlanması için gereken süreyi, kullanıcılara ulaşan sorunların sayısını ve ne sıklıkta teslimat yaptığınızı gösterebilir. Onlarca sayıya ihtiyacınız yoktur. Kolayca okuyup tartışabileceğiniz birkaç sayıya ihtiyacınız vardır. Dışarıdan gelen geliştiricileri yönetirken ve ekibi büyütürken bu metrikler sabit kalırsa veya iyileşirse, kurulumunuzun kaliteyi desteklediğini bilirsiniz. Düşüş olursa, kurallarınızı, kapsamınızı veya görevlerinizi gözden geçirmek için erken bir sinyal almış olursunuz.

İletişim modelleri, kurallar ve sayılar kadar önemlidir. Birçok karma geliştirme ekibi, insanlar farklı yerlerden veya zaman dilimlerinden çalıştığı için dağıtılmış çevik ekipler olarak da kabul edilir. Geliştirme ekiplerinin ilerlemesi uzun görüşmelere bağlı kalmasın diye eşzamansız iletişime ihtiyaçları vardır. Kısa yazılı güncellemeler, açık görev notları ve durum için basit etiketler çok yardımcı olur. İyi yazılmış güncellemeler, tüm mühendislerin zaman içinde ürüne katılmasını, onu takip etmesini ve geliştirmesini kolaylaştırır. Canlı görüşmeler hala önemlidir, ancak artık kararların alındığı tek yer değildir.

Dışarıdan kişileri dahil etme şekliniz de kaliteyi etkiler. Onları belirsiz hedefleri olan ayrı bir akış olarak görürseniz, ürünün tam sahipliğini hissetmezler. Onları mevcut ekiplere tek bir kurallar dizisi altında eklerseniz, diğer ekip üyeleri gibi davranabilirler. Bazı şirketler bunun için ekip genişletme yapısını kullanır ve iç ve dış kişileri tek bir lider altında birleştirir. Ortak hedefler, ortak araçlar ve ortak incelemeler, yazılım geliştirmede kod kalitesi için herhangi bir ağır kontrol belgesinden daha fazla fayda sağlar. Zamanla, insan ve iş karışımını ayarlayabilirsiniz, ancak ortak çerçeve aynı kalır.