Ölçeklemeye Başlamadan Önce Bilinmesi Gereken 10 Ölçeklenebilirlik Ön Koşulu

Yazılım geliştirme işinde yeterince uzun süredir çalışıyorsanız, büyük olasılıkla şu kâbusu yaşamışsınızdır:

1. Müşteriye, kimsenin itiraz etmeye cesaret edemediği gerçekçi olmayan derecede kısa bir zaman diliminde birçok özellik sunulacağı sözü verilir.
2. Daha sonra, son teslim tarihi tehlikeli derecede yaklaşınca, yetki sahibi biri son teslim tarihine yetişmek için soruna daha fazla ekip dâhil etmeye karar verir.
3. İşler dağılmaya başlar.

Tanıdık geldi mi?

Bu makalede, o kâbus senaryosunu bir daha yaşamamak (veya bunu yaşamayacak kadar şanslıysanız, tamamen önlemek) için ne yapmanız gerektiğini açıklayacağım.

Bu makaledeki içgörülerim yazılım geliştirme ekiplerini ölçeklendirme deneyiminden geliyor; ancak temel teoriyi bir işletmeyi ölçeklendirmek veya herhangi bir sektörde bir ekip büyütmek için uygulayabilirsiniz. Hazır ölçeklendirme çerçevelerinden biri olan Large Scale Scrum (LeSS), Scrum@Scale veya SAFe'i benimsiyor olsanız bile bunu yararlı bulacaksınız.

Bunun nedeni, bu metodolojilerde hiç bahsedilmeyen bazı önemli ölçeklenebilirlik unsurlarına odaklanmamdır: Ölçeklendirmenin doğasına ilişkin çoğu zaman unutulan veya göz ardı edilen temel gerçek.

Ölçeklendirmenin Temel Yasası

Ölçeklendirmenin Temel Yasası, projeler ölçeklendirildiğinde gerçekleşenlere ilişkin deneysel bir gözlemdir:

Ölçeklendirme kötüyü büyütür ve iyiyi zorlaştırır.

Bu ifadeyi ben oluşturdum; ancak bu içgörüyü ortaya koyan ne tek kişi benim ne de ilk kişi.

Birkaç ölçeklenebilirlik örneğiyle Yasa'nın pratikte ne anlama geldiğine bakalım.

1. Örnek: İletişim ve Ölçeklenebilirlik

İlk ve en belirgin örnek iletişimdir. Bir projedeki kişi sayısı arttığında iletişim kanallarının sayısının da arttığı bilinen bir gerçektir. İletişim kanalları başlangıçta yeterince iyi değilse ölçeklendirme sorunu daha da kötüleştirir.

Öte yandan, iletişim kanalları başlangıçta iyiyse ölçeklendirme, yalnızca artan kişi sayısı nedeniyle değil, kişilerin dağılımı nedeniyle de bazı zorluklar ortaya çıkarır. Genellikle yeni ekipler farklı konumlarda oluşturulur ve bu da iletişim kanallarında değişiklik yapılmasını zorunlu kılar; örneğin yüz yüze toplantılardan görüntülü konferansa geçmek veya beyaz tahtanın yerine elektronik bir araç kullanmak gibi.

2. Örnek: Sürekli Entegrasyon/Sürekli Teslimat ve Ölçeklenebilirlik

Ölçeklendirmenin Temel Yasası'nı Sürekli Entegrasyon (CI) ve sürekli teslimat (CD) işlem hatlarında da görürüz. Yalnızca bir ekip olduğunda işler oldukça basittir.

Bir ekipten iki ekibe geçildiğinde CI ve CD sistemleri daha karmaşık hâle gelir; genellikle n ekip olduğunda CI işlem hatlarının sayısı n+1 olma eğilimindedir (ekip başına bir işlem hattı ve entegrasyon için bir işlem hattı). Bunun ortamların hazırlanması ve ekipler arasındaki koordinasyon üzerinde belirgin etkileri vardır.

3. Örnek: Geri Bildirim Döngüleri ve Ölçeklenebilirlik

Son bir örnek: geri bildirim döngüleri. Daha büyük projelerde geri bildirim döngüleri daha uzundur. Bu nedenle sistemi yinelemeli bir şekilde iyileştirmek çok daha zor hâle gelir ve yanlış ürünü geliştirme olasılığı artar.

Bunlar, ölçeklendirmenin beraberinde getirdiği zorluklardan yalnızca üç örnektir. Eminim siz de daha birçok örnek düşünebilirsiniz.

İşin içinde olan ödünleşimleri kabul etmeye istekli olduğunuzu varsayalım. Bundan sonra ihtiyacınız olan şey, ölçeklenebilirliğinizi kanıtlamak için projenizin bazı önemli ön koşulları karşılamasıdır.

Ölçeklendirme İçin 10 Ön Koşul

Ölçeklenebilir bir işletmeye, projeye veya ekibe sahip olup olmadığınız aşağıda listelenen çeşitli ön koşullara bağlıdır. Bu ön koşulları karşılıyorsanız ölçeklenebilirliğiniz yüksektir. Öte yandan, bunlardan herhangi biri karşılanmıyorsa başarısızlık olasılığı büyük ölçüde artar.

1. Açık ve Paylaşılan Hedeflerin Varlığı

Bu zaten olması gereken bir şey gibi görünmeli; ancak deneyimlerime göre açık ve paylaşılan hedeflerin bulunmaması son derece yaygındır. Bunlar olmadan ekipler farklı yönlere çekiştirir ve yararlı bir şey sunmak daha zor hâle gelir.

2. Uygun Ölçümlerin Kullanılması

Proje ne kadar büyükse, alınan kararların etkisini ölçebilmek o kadar önemlidir. Örneğin, yeni bir ekibin eklenmesi projenin teslimat yapma becerisini geliştirdi mi? Kalitenin düşmesine neden olacak kadar ekipleri zorluyor muyuz? Ekipler birlikte iyi çalışıyor mu, yoksa birbirlerinin çalışmalarını mı engelliyor?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

3. Uygun Bir Mimari

Sistemin “şekli” ekiplerin yapısıyla örtüşmüyorsa, daha fazla ekip eklemek işleri yalnızca kötüleştirir. Bu, pratikte kanıtlanmış, iyi bilinen deneysel bir gözlem olan Conway Yasası’nın doğrudan bir etkisidir.

4. Yönetimsel ve Teknik Becerilerin Mevcudiyeti

Beceri eksikliğinden kaynaklanan sorunların olumsuz etkisi, proje büyüdükçe daha da artar.

5. İyi İletişim Kanalları

Sürece dahil olan kişi sayısı arttıkça iletişim de artar. Başarılı bir ölçeklendirme, düzenli ve verimli iletişim gerektirir.

6. İyi Önceliklendirme ve Planlama

Deneyimlerime göre, uygun önceliklendirme ve planlama eksikliği proje başarısızlıklarında çok yaygın bir etkendir. Özellikle birden fazla ekip sürece dahil olduğunda, önceliklendirme ve planlama faaliyetleri gecikmelerin ve eşgüdüm eksikliğinin etkilerini azaltacak önlemleri içermelidir.

7. İyi Gereksinim Çıkarma ve Yönetimi

Bu konu, önceliklendirme ve planlamayla el ele gider. Ayrıca yanlış, yanlış anlaşılan veya gereksiz gereksinimlerin etkisi, ekip sayısı arttıkça daha da büyür.

8. Yüksek Kaliteli Çalışma

Proje ne kadar büyükse, düşük kalitenin olumsuz etkisi de o kadar büyüktür. Bazı patolojik (ve yaygın) senaryolarda, bazı hatalar özellik haline gelebilir; çünkü bunları düzeltmeye yönelik geri bildirim döngüleri o kadar uzun olabilir ki diğer ekipler bunları etkisizleştirmek için geçici çözüm yolları tasarlamış olabilir.

9. Kaynakların Mevcudiyeti

Daha fazla ekip, daha fazla masa, bilgisayar, araç ve ortam gerektirir.

10. Kapsamlı Otomasyon

Her manuel faaliyet, kişi ve ekip sayısı arttıkça etkileri daha da kötüleşen bir darboğazdır. Buna (çok yaygın) bir örnek, üretim sürümünden önce gerilemelerin ortaya çıkmadığından emin olmak için gerçekleştirilen manuel test faaliyetleridir. Deneyimlerime göre bu, her projedeki, özellikle de birden fazla ekibin bulunduğu projelerdeki en büyük darboğazlardan biridir.

Erken Ölçeklendirmeye Dikkat Edin

Ölçeklenebilirlik, girişimlerin ve seri girişimcilerin gündeminin en üst sıralarında yer alır ve erken ölçeklendirme konusunda bize öğretecekleri bir iki ders vardır.

Bir işletmeyi, ekibi veya kuruluşu başarılı bir şekilde ölçeklendirmek için gereken ön koşulları gerçekten karşılamadan önce ölçeklendirme girişiminde bulunursanız, girişimcilik camiasının “erken ölçeklendirme” olarak adlandırdığı durumla karşılaşırsınız.

Seri girişimci Jim Pitkow’un erken ölçeklendirme için yaptığı basit tanım:

Erken ölçeklendirme: talebe dayalı büyüme yerine, talep beklentisiyle büyümek.

Gerçekten de uygun şekilde ölçeklendirme zaman alır ve gerçek ölçeklenebilirlik, yapay olarak dayatılan yalnızca büyümek ve daha fazla işi daha hızlı yapmak düşüncesinden değil, talebin doğurduğu gerçek bir ölçek ihtiyacından kaynaklanır.

Girişimcilik camiası, ölçeklendirme zamanının gelip gelmediğini düşünürken ekiplerimize ve projelerimize aktarabileceğimiz birkaç ders sunuyor. İşte Startup Genome’un Erken Ölçeklendirme Üzerine Ek Raporu’ndan birkaç istatistik:

• Uygun şekilde ölçeklenen girişimlerin ekip boyutlarına ulaşması, erken ölçeklenen girişimlere göre %76 daha uzun sürer.
• Hızlı büyüyen internet girişimlerinin %74’ü erken ölçeklendirme nedeniyle başarısız olur.
• Uygun şekilde ölçeklenen girişimler, erken ölçeklenen girişimlere göre yaklaşık 20 kat daha hızlı büyür.

Girişimcilikle ilgili daha fazla istatistik ilginizi çekiyorsa, Amerika’daki girişimcilik açısından en önde gelen eyaletler üzerine yaptığımız araştırmaya göz atın.

Ölçeklendirmeye Gerçekten Hazır mısınız?

Projeniz iyi yönetiliyorsa ve yukarıdaki ön koşulları karşılıyorsa, sıradaki sorunuz şu olmalıdır:

“Kaç ekip verimli bir şekilde katkıda bulunabilir?”

Bu soruyu bir sonraki bölümde yanıtlayacağız.

Ölçeklenebilirliğin Sınırı Nedir? Brooks ve Amdahl Yasaları

Bir yazılım projesine daha fazla kişi eklemenin üretkenliği mutlaka artırmayacağı iyi bilinen bir gerçektir.

Aslında çoğu durumda daha fazla kişi eklemek, üretkenlikte ciddi bir düşüşe yol açar.

Fred Brooks bu gözlemini, Brooks Yasası olarak bilinen Efsanevi Adam-Ay adlı kitabında dile getirmiştir:

“Geç kalmış bir yazılım projesine iş gücü eklemek, projeyi daha da geciktirir […] Bir projenin ay cinsinden süresi, sıralı kısıtlamalarına bağlıdır. Kullanılabilecek maksimum kişi sayısı, bağımsız alt görevlerin sayısına bağlıdır. Bu iki nicelikten, daha az kişi ve daha fazla ay kullanılarak takvimler türetilebilir[…]. Ancak daha fazla kişi ve daha az ay kullanarak uygulanabilir takvimler oluşturulamaz.”

Yukarıdaki alıntının ikinci yarısı, bana göre en ilginç kısım. Aslında bu bölüm, eşzamanlı bir sistemin teorik olarak elde edilebilecek maksimum hızlanmasını veren bir formül olan Amdahl Yasası'nın sade bir dille ifade edilmiş hâlidir:

Amdahl Yasası

Hızlanma = 1 / (s + p / n )

Burada:

s = seri görevlerin yüzdesi

p = paralel görevlerin yüzdesi

s + p = 1

n = işlemci sayısı (bizim durumumuzda ekipler)

Aslında birden fazla ekibin bulunduğu proje, her ekibin bir işlem birimi olduğu bir tür eşzamanlı sistemdir. Uygulamada Amdahl Yasası, eşzamanlı olarak gerçekleştirilebilecek iş miktarının yapılması gereken seri iş miktarıyla sınırlı olduğunu belirtir.

Basitçe söylemek gerekirse bu, belirli bir sırayla yapılması gereken işlerin, ekiplerin aynı anda üzerinde çalışabileceği iş miktarına kısıtlamalar getireceği anlamına gelir.

Yazılım Geliştirme Bağlamında Seri İş Nedir?

Yazılım ekiplerini etkileyen seri işin ne tür bir iş olduğunu merak ediyor olabilirsiniz.

İşte birkaç örnek (eminim daha birçok örnek düşünebilirsiniz):

• Entegrasyon ve dağıtım işlem hatlarıyla ilgili her türlü iş
• Farklı ekipler tarafından paylaşılan kodda yapılan yazılım değişikliklerini birleştirmek
• Her türlü eşzamanlama—örneğin, çalışmaya devam etmeden önce başka bir ekibin teslimatlarına ihtiyaç duyan bir ekip
• Kaynakların sağlanmasını beklemek

Amdahl Yasasını Ekipleri Ölçeklendirmeye Uygulamak

Aşağıdaki grafik, ekip sayısı artırıldığında Amdahl Yasası'nın üretkenlik üzerindeki etkilerini göstermektedir.

Ekip sayısındaki artışla birlikte üretkenliğin doğrusal olmayan bir şekilde artacağını, bir tepe noktasına ulaştıktan sonra ise yeniden düşeceğini görebiliriz.

Amdahl yasasının bir gösterimi: Teslimat hacmi ekip sayısıyla birlikte artar, ancak yalnızca belirli bir noktaya kadar—ve bu genellikle yöneticilerin umduğu şey değildir.

Bu makaleden yalnızca bir şey hatırlayacaksanız, o da şu olsun:

Ekip sayınızı artırmak teslimat hacmini artırabilir—ancak yalnızca belirli bir noktaya kadar.

Peki, Belirli Bir Proje İçin İdeal Ekip Sayısı Nedir?

Ne yazık ki belirli bir proje için ideal ekip sayısını önceden hesaplayabileceğiniz denklemler yoktur. Tek yol, üretkenlik ve kalite gibi unsurları ölçmek için bir dizi proje metriği kullanmak ve ekipler eklendiğinde veya çıkarıldığında neler olduğunu görmektir. Benim önerim, 3-6 kişilik tek bir ekiple küçük başlamanız ve yalnızca gerektiğinde ve gerektikçe ölçeği artırmanızdır.

Bir noktada, ekip sayısının zirvesine zaten ulaştığınızı, ancak projenizin hâlâ taahhütlerini yerine getiremediğini fark edebilirsiniz. İşte bu noktada önceliklendirme ve iletişim becerileriniz işe yarar; çünkü müşterilerinizle bazı zorlu görüşmeler yapmanız gerekebilir.

Ekip Yapısıyla İlgili Değerlendirmeler: Özellik Ekipleri mi, Bileşen Ekipleri mi?

Projeye yeni bir ekip eklediğinizde, bu ekip nasıl çalışmalıdır? Başlangıç olarak kendinize şu iki soruyu sorun:

1. Müşterinin görebileceği özellikleri uçtan uca geliştirmekten mi, yoksa hedeflerine ulaşmak için sistemde bir şeyleri değiştirmekten mi sorumlu olacaklar?
2. Kullanıcının görebileceği bazı işlevlerin bir bölümünü sağlayan belirli bir bileşen üzerinde çalışmaktan mı sorumlu olacaklar?

#1 için evet dediyseniz, ekip bir özellik ekibi olacaktır.

#2 için evet dediyseniz, ekip bir bileşen ekibi olacaktır.

Doğru Ekip Yapısını Seçmek İçin İpuçları

Uygun ekip yapısını ve ekip organizasyonunu seçmek çok önemlidir, ancak bu kolay değildir. Günümüzde özellik ekipleri çoğu durumda tercih edilen seçenek gibi görünmektedir. Ancak bu seçim çoğunlukla verilere değil, alışkanlığa veya rutine dayanır.

Gerçek şu ki, “duruma bağlıdır”. Daha spesifik olarak, sistemin mimarisine bağlıdır. Yazılım projeleri, Mel Conway tarafından yapılan ampirik bir gözlem olan Conway Yasası olarak bilinen ilkeyi izleme eğilimindedir:

“Sistemleri tasarlayan kuruluşlar… bu kuruluşların iletişim yapılarının kopyası olan tasarımlar üretmekle kısıtlanır”

Başka bir deyişle, ekip yapısının “şekli” sistemin “şekliyle” örtüşmelidir; aksi takdirde proje ciddi sorunlarla karşılaşacaktır.

Bu nedenle yöneticilere her zaman ekip yapısıyla ilgili kararlara kıdemli mimarları ve teknik liderleri dâhil etmelerini öneriyorum; aksi takdirde yöneticiler, bunun farkında olmadan (ve uygun becerilere sahip olmadan) aslında sistem tasarımı yapmış olurlar. Bu da proje başarısızlığı riskini büyük ölçüde artırabilir.

Ölçeklenebilirliğin İki Paradoksu

Çok sayıda büyük ölçekli projede danışman olarak edindiğim deneyime göre, çoğu durumda projeler yanlış nedenlerle ölçeklenmektedir.

Uygulamada gördüklerimi özetleyen iki paradoks geliştirdim:

Ölçeklendirmenin Birinci Paradoksu

Çoğu proje, ölçeklendirme için gerekli ön koşulları karşılamadığı için büyütülür

Ölçeklendirmenin İkinci Paradoksu

Ölçeklendirme için gerekli ön koşulları karşılayan projelerin ölçeklendirme ihtiyacı daha azdır

İlk paradoks, çoğu durumda projelerin iyi yönetilmedikleri için yavaş ilerlediğini söyler.

İkinci paradoks ise iyi yönetilen projelerin, iyi yönetildikleri için ölçeklendirme ihtiyacının daha az olacağını söyler.

Aslında gördüğüm en üretken projelerin yalnızca bir veya iki küçük ekibi vardı ve ölçeklendirme için gerekli tüm ön koşulları karşılıyorlardı. Dâhil olduğum büyük ölçekli projelerin hiçbirinde ölçeklendirme için gerekli tüm ön koşulların karşılandığını görmedim. Aslında bunların hepsi, ön koşullardan herhangi birini karşılamakta çok sayıda sorun yaşıyordu.

Sorunlar ve gecikmeler yaşayan bir projede yer alıyorsanız verebileceğim en iyi öneri, projeyi büyütmeyi düşünmeden önce karmaşayı küçültmenizdir.

Ekiplerinizi Doğru Şekilde Ölçeklendirmek İçin Çıkarılacak Dersler

Yazılım ekiplerini ölçeklendirmek kolay değildir ve son derece dikkatli yapılmalıdır. Ayrılmadan önce, bir yazılım geliştirme ekibini ölçeklendirmenin en etkili yolunu bulmaya ilişkin bazı son düşünceler:

1. Ölçeklenebilirlik için gerekli ön koşulları karşılamaya çalışırsanız, ekibi küçük tutabileceğinizi ve daha büyük bir ekibin beraberinde getirdiği tüm sorunlardan kaçınabileceğinizi görebilirsiniz.
2. Öte yandan, projeniz zaten büyük ve sorunlarla boğuşan bir projeyse, önce karmaşayı küçültmeye odaklanın.

Bu makaleyi okuduktan sonra atmanızı önerdiğim ilk adımlar şunlardır:

1. Sahada neler olduğunu öğrenin
2. Mevcut durumu ve alınan kararların kalitesini değerlendirebilmek için bazı ölçümler uygulayın.