Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir!

Brooks yasası, geciken bir yazılım projesine ek yazılımcı eklemenin işleri daha fazla geciktireceği gözlemine dayalı bir yasadır. Bu yasa geniş hatlarıyla takip edildiğinde birçok projeye ek kaynak (özellikle insan gücü) eklemenin faydasız ve hatta üretkenliği olumsuz yönde etkileyen bir yol olduğu ortaya çıkmaktadır.

Brooks yasası, kişisel ve kurumsal üretkenlik alanlarında birçok etkiye sahiptir ve bu sebeple kavranması önemlidir. Bu çerçevede makalemizde Brooks yasasını deteylarıyla öğrenecek ve pratikte nasıl ele alabileceğinizi göreceksiniz.

Brooks Yasası Örnekleri

Brooks yasasının klasik bir örneği, programın gerisinde kalan bir yazılım projesine daha fazla yazılım geliştirici atanmasıdır. Bu atama; yeni geliştiricilerin eğitimi, geciken görevlerin birden fazla kişi arasında paylaştırılamaması gibi gerekçelerle daha fazla gecikmeye sebep olur ve yeni geliştiriciler sürecin daha hızlı bir şekilde ilerlemesini sağlayamaz.

Brooks yasasının bir başka örneği de küçük bir ekip tarafından hızlı bir şekilde halledilebilecek bir projeye gereksiz yere çok sayıda kişi eklenmesi ve böylelikle iletişim ve karar alma süreçlerinin çok daha yavaş hale gelmesi nedeniyle gecikmesidir.

Buna ek olarak Brooks yasasının arkasındaki mantık, "dokuz kadın bir ayda bir bebek yapamaz" mizahi atasözünde vurgulanmaktadır. Zira belirli görevler iş bölümü içinde paylaştırılamaz ve bu sebeple projelere ek insan gücü eklemek genellikle beklenen faydaları yaratmayan bir yöntem olarak göze çarpmaktadır. Aynı konu "yüz arşın derinliğinde yüz kuyu yerine yüz arşın derinliğinde bir kuyu yeğdir" gibi deyişlerle de vurgulanmaktadır.

Brooks yasasının ortaya atıldığı kitapta önemli bir örnek karşımıza çıkmaktadır:^[1]

Temel bir yazılım projesi programın gerisinde mi kalmış? İnsan gücü ekleyelim. Önceki figürlerin de gösterdiği gibi bu işe yarayabilir veya yaramayabilir.

Bu konuyu bir örnek ile ele alalım. Diyelim ki bir görev bir kişinin 12 ayda bitirebileceği zorlukta bir görev. Üç kişi dörder aylık periyodlarda çalışmak üzere görevlendirilsin ve her ayın sonunda A, B, C, D olarak anacağımız belirli kontrol noktalarımız olsun.

Şimdi düşünelim, aradan iki ay geçmiş ve A kontrol noktasına henüz gelinememiş. Burada bir yönetici neler yapabilir?

Görevin zamanında bitirilmesi gerektiğini düşünebilir ve görevin ilk bölümünün (0-A noktası) yanlış ölçeklendirildiğini varsayabilir. Bu çerçevede 9 ay kaldığını ve iki ay geçtiğini düşünerek projenin 4.5 insanla yürütülebileceğini; yani asil 3 çalışanın yanına 2 çalışan daha vermeyi tercih edebilir.

Görevin zamanında bitirilmesi gerektiğini düşünebilir ve görevin tamamen yanlış ölçeklendirildiğini varsayarak 18 ayda yetiştirebilecekleri sonucuna varabilir. Buradan da 18 aylık işi 9 kişinin yetiştirebileceğini düşünerek asil 3 çalışanın yanına 6 kişi daha verebilir.

Erteleyebilir. Deneyimli bir donanımcı olan P. Fagg'in konuya ilişkin tavsiyesini seviyorum; "Küçük hata olmaz." Yani bir iş dikkatli ve kapsamlı şekilde yapılacaksa erteleme ve yeni zaman çizelgesinde işe yeterli zaman verme önemlidir ki proje bir defa daha ertelenmesin.

İşi kırpabilir. Kırpma dediğimiz şey, takımın programdan bir defa şaştığını görünce zaten pratikte de yaşanmaktadır. Gecikmenin ikincil maliyetlerinin çok yüksek olduğu durumlarda kırpma tek mantıklı opsiyon olarak karşımıza çıkmaktadır. Yöneticimiz bu noktada kırpma işlemini dikkatli ve resmi bir şekilde yapabilir, işi erteleyebilir veya projenin hızlı tasarlanması ve test sürecinin tamamlanamamasına (yani bu alanların kırpılmasına) seyirci kalabilir.

İlk iki durumda müdahale edilmemiş görevin dört ayda teslim edileceğini yönünde bir ısrar felaketle sonuçlanır. Bunun yerine süreci iyileştirmeye yönelik etkiler düşünülmelidir. Örneğin, ilk seçenek için...

İki yeni yazılımcının, ne kadar yetkin ve işe ne kadar erken başlamış olursa olsun, görev konusunda deneyimli asil çalışanlardan eğitim alması gerekmektedir. Bu eğitimin bir ay süreceği düşünülürse bu bir aylık sürenin üç aylık iş süresinden düşülmesi gerekir. Buna ek olarak üçe bölünmüş görevin şimdi beşe bölünmesi gerekecektir; yapılan işlerin bir kısmı kaybolur ve sistem testlerinin süresinin uzatılması gerekir. Bu çerçevede elde üçüncü ayın sonunda geriye 7 aylık bir işten daha fazla iş kalır ve bu işi yapmak için 5 eğitimli personel ve bir aylık bir kayıp söz konusudur. Projeye hiçkimse eklenmese de aynı gecikme yaşanacaktır...

Bu işin dört ayda bitirilebilmesi için, iş yükünün yeniden dağıtılması ve ek sistem testleri hesaba katılmadığı bir senaryoda, projeye 2. ayın sonunda iki yerine dört kişinin atanması gerekmektedir. İş bölümünden ve sistem test etkilerinden sorumlu başkaca kimseler de olmalıdır. Ekipteki üye sayısı üçle başlamış ve en az yedi olmuştur. Dolayısıyla takım organizasyonu ve iş bölümü yalnızca sayıca değil, birçok şekilde değişmelidir.

Üçüncü ayın sonunda durumun oldukça kötü olduğu açıktır. Alınan bütün kararlara rağmen A kontrol noktasına hala ulaşılamamıştır. Bütün bu döngüyü yineleyip daha da fazla personel atamak mantıklı görünmektedir. İşte tam da burada delilik başlar.

Yukarıdaki personel atama senaryosunda yalnızca ilk kontrol noktasına kadar olan işin yanlış ölçeklendirildiği varsayılmıştır. Bir kimse A noktasında tüm iş programının bir hayal ürünü olduğunu düşünür ve iyileştirici bir etki yaratmaya çalışırsa ortaya, orijinal 3 personelin herhangi bir destek olmaksızın teslim tarihini erteleyerek çıkaracağı işten çok daha kötü bir iş çıkar.

Not: Fred Brooks'a atfedilen ve Brooks yasası ile ilişkili komik bir deyiş de "bir yazılımcının bir ayda yapabileceği işi iki yazılımcı iki ayda yapar" deyişidir.

Pexels

Diğer Alanlarda Brooks Yasası

Brooks yasasının orijinal formülasyonu, geç kalan yazılım projelerine insan gücü eklemenin daha fazla gecikmeye sebep olduğunu savunmaktadır. Ancak bu kavramı üç ana bağlama genişleterek daha genel ve dolayısıyla daha geniş bir bağlam yelpazesinde kullanmak da mümkündür:

• Brooks yasası yazılım projeleri dışındaki alanlara da uygulanabilir (farklı türlerde işler, akademik ve hobi projeleri).
• Brooks yasası gecikme haricindeki olumsuz sonuçlara da uygulanabilir. Örneğin bir yazılım projesine ek personel atanması, gecikme haricinde daha kötü bir ürün kalitesine veya ekip üyeleri arasındaki anlaşmazlıkların artmasına sebep olabilir.
• Brooks yasası insan gücünden başka kaynaklara da uygulanabilir. Örneğin bir projeye daha fazla personel atanması yerine daha fazla para harcanması, eğer proje para temelli sebeplerle gecikmiyorsa projenin geliştirilme hızını artırmayabilir.

Buna dayanarak Brooks yasasının genelleştirilmiş bir hali aşağıdaki şekilde formüle edilebilir:

Bir projeye daha fazla kaynak eklemek bazen yararsız olabilir, hatta ters etki yaratabilir.

Ayrıca, bir projeye kaynak eklemenin faydalı olduğu durumlarda bile projeye ne kadar çok kaynak eklenirse, ek kaynakların o denli az etkin olacağı bir senaryo yaşanabileceğini, yani bir azalan getiri sorunu da çıkabileceğini göz önünde bulundurmak gerekir.

Brooks Yasasının Mantığı

Brooks yasası, bir projeye daha fazla personel atamanın aşağıdaki gibi çeşitli sorunlar nedeniyle daha hızlı tamamlanacağı anlamına gelmediği fikrine dayanmaktadır:

• Öğretme süresi, halihazırda proje üzerinde çalışan kişilerin yeni gelenleri eğitmek için harcaması gereken süredir. Örneğin bir yazılım projesi bağlamında bu, mevcut kodu açıklamak için zaman harcamak veya insanları projede kullanılan belirli teknik araçlar konusunda eğitmek gibi şeyleri içerebilir.
• Öğrenme süresi, yeni kişilerin projeye katıldıktan sonra üretken hale gelmeleri için geçen süredir.
• İş yapmak yerine iletişim için harcanan zaman olarak iletişim iş yükünün artması. Fred Brooks'un konuyla ilgili kitabında belirttiği gibi: "Bir projede n sayısında çalışan varsa, iletişim kurulabilecek (n2-n)/2 arayüz vardır...", bu da 2 kişinin aralarında bir arayüz, 3 kişinin 3 arayüz, 4 kişinin 6 arayüz, 5 kişinin 10 arayüz, 6 kişinin 15 arayüz ve 10 kişinin 45 arayüz olduğu anlamına gelir.
• Sınırlı paylaştırılabilirlik, belirli görevleri ayrı kişiler tarafından ele alınabilecek bölümlere ayırma konusundaki sınırlı imkân anlamına gelir.

Bu tür konular, konuyla ilgili orijinal kitapta ayrıntılı olarak tartışılmaktadır:^[1]

Programda kaymalar olduğu fark edildiğinde doğal (ve geleneksel) yaklaşım işe eleman eklemektir. Bu da yangına körükle gitmek gibi işleri çok daha kötü bir hale sokar. Daha fazla ateş daha fazla körük gerektirir ve felaketle sonuçlanan döngü başlamış olur.

Bu konuda sıkıntılardan biri iş bazında süre verme ve takvim yaratmada kullanılan emek biriminde, iş ayında (bir personelin bir ayda yapabileceği iş) karşımıza çıkmaktadır. Maliyet, çalışan kişi ve takvim bazında ay sayısı ile elbette değişmektedir; ancak ilerleme değişmez. Dolayısıyla bir işin boyutunu belirlemek için iş ayı ölçü birimini kullanmak tehlikeli ve aldatıcı bir mittir. Böylesi bir kullanım ay ve personel teriminin aynı işlevde kullanılabileceği, yani tüm personelin bir ayda aynı oranda iş çıkarabileceği varsayımına götürür.

Halbuki personel ve ay terimleri aralarında hiçbir iletişim bulunmayan birçok işçi arasında bölüştürülebilen görevler için geçerlidir. Bu buğday hasadında veya pamuk toplamada geçerli olabilir; ancak sistem programlamaları için asla geçerli değildir.

Dizimsel kısıtlardan ötürü bir görev parçalarına bölünüp bölüştürülemediğinde harcanan ek çabanın takvime hiçbir etkisi olmaz. Ne kadar kadın görevlendirilirse görevlendirilsin, bir çocuk dokuz ayda doğar. Debugging işleminin dizimsel doğasından ötürü birçok yazılım geliştirme projesi de benzeri bir özelliğe sahiptir.

İşlerin bölünebileceği ancak alt-işlerin yürütülmesinde iletişimin gerekli hale geldiği görevlerde ise iletişim gerekliliği yapılacak işlerden biri olarak kabul edilmelidir. Bundan ötürü yapılabilecek en iyi iş bile orijinal bir ekibin birkaç ay geç çıkaracağı işten daha kötü kalitede olmaktadır.

Alınan bu iletişim yükü de eğitim ve iç iletişim olmak üzere iki parçadan oluşmaktadır. Her bir yeni çalışan teknoloji, amaçlar, genel strateji ve iş planı alanlarında eğitilmelidir. Bu eğitim küçük parçalara bölünemez; dolayısıyla yeni personel sayısı arttıkça harcanacak emek de doğru orantıyla artmaktadır.

İç iletişimde ise durum daha kötüdür. Görevin her bir bölümünün diğer bölümlerle ayrı ayrı koordine edilmesi gerekiyorsa harcanacak çaba n(n-1)/2 kadar artar. Üç işçi, iki işçinin üç katı kadar ikili iletişim gerektirir; dört işçi iki işçinin altı katı kadar iletişim gerektirir. Dahası, sorunları ortaklaşa çözmek için üç, dört, vb. işçi arasında konferanslar yapılması gerekiyorsa işler daha da kötüleşir. İletişim kurmak için harcanan ek çaba, asıl görev kapsamında yapılan iş bölümünü tamamen etkisiz hale getirir.

Yazılım geliştirme, karmaşık iç ilişkilerin meydana getirdiği bir sistemsel çaba olduğu için iletişim çabaları had safhadadır ve yeni personelin gelmesiyle yapılan iş bölümü çerçevesinde personel başına düşen bağımsız görev süresinde artışı doğrudan ekarte eder. Bu noktada bir işe daha fazla personel atamak süreci kısaltmak yerine uzatır.

Buna ek olarak konu hakkında yürütülen birçok çalışmada iletişim ve organizasyon sorunları ele alınmıştır. Örneğin bir kitapta şu sözlere yer verilmektedir:^[2]

...bir grup büyüdükçe grubu oluşturan bireyler arasında daha fazla anlaşma ve organizasyon gerekecektir ve bu anlaşma ve organizasyon çabalarına katılacak kişi sayısı doğal olarak artacaktır. Tabi ki tüm grubun organize olması gerekmez, bazı alt gruplar kendi içinde kolektif çalışmalarını yürütebilir; ancak grup büyüdükçe grubu oluşturan elemanlara ulaşmak ve bir alt grubu organize etmek zorlaşacak, hatta bu alt grupları oluşturan bireyler de küçük pazarlıklara devam ederek grubun tamamına zarar verecek ve nihayetinde bir anlaşmaya varma veya organizasyon çabası hemen hemen her koşulda daha zor olacaktır. Kısacası organizasyon maliyeti bir gruptaki birey sayısıyla doğru orantılı olarak artmaktadır...

Bir grubun önceden mevcut bir organizasyonu olmadığında ve ulaşmak istediği kolektif bir hedefin doğrudan kaynak maliyetleri herhangi bir bireyin karlı bir şekilde üstlenebileceğinden daha fazla olduğunda, yükün nasıl paylaşılacağı konusunda bir anlaşma sağlamak ve kolektif hedefe ulaşma çabasını koordine veya organize etmek için ek maliyetlerin göze alınması gerekir. Bunlar grup üyeleri arasındaki iletişim maliyetleri, pazarlık maliyetleri ve herhangi bir resmi grup organizasyonu oluşturma, personel sağlama ve sürdürme maliyetleridir.

Ayrıca, insan gücünün artırılması, kişisel sorumluluk ve motivasyonda azalmalar gibi diğer sorunlara yol açarak ironik şekilde genel ekip verimliliğini düşürebilir.

İş ve insan gücünden bağımsız olarak diğer kaynaklar (zaman ve para) söz konusu olduğunda da benzer sorunlar baş göstermektedir. Örneğin araştırma bağlamında belirli bir biyolojik örneğin büyümesi bir ay sürüyorsa ve günde tam olarak bir saatlik çalışma gerektiriyorsa, bir araştırmacıya bunun üzerinde daha fazla zaman harcamasını söylemek daha hızlı büyümesini sağlamayacaktır ve esasında bir zaman kaybıdır. Alternatif olarak iş geliştirme bağlamında, bir çalışanın bir görevi tamamlamak için ihtiyaç duyduğu en iyi araçların toplam maliyeti 1.000 $ ise, ekstra araçlar için 5.000 $ harcamasını söylemek görevi tamamlama hızlarını etkilemeyecek ve bu nedenle para israfı olacaktır. Dahası, bu iki durumda da ekstra kaynakların harcanması, örneğin araştırmacının hata yapma olasılığını ve numuneyi kontamine etme olasılığını artırarak veya çalışanın gereksiz ek araçlar seçerek zamanını harcamasıyla ters etki bile yaratabilir.

Not: Bununla yakından ilişkili bir kavram da "iş, tamamlanması için mevcut olan zamanı dolduracak şekilde genişler" atasözüyle özetlenen Parkinson yasasıdır. Bu, insanların belirli bir görevi yerine getirmek için ne kadar çok zaman alırsa görevin, daha erken bitebilecek olmasına rağmen, o kadar uzun süreceği anlamına gelir.

Pixabay

Brooks Yasası Hakkında Akılda Tutulması Gerekenler

Brooks yasası ile ilgili temel bir uyarı, bu yasanın belirli bir durumda geçerli olup olmamasının aşağıdaki sebeplere bağlı olduğu ve Brooks'un kendisinin dahi bu kavramı akıl almaz bir basitleştirme olarak gördüğüdür:^{[1], [3], [4], [5], [6]}

• Şu anda proje üzerinde çalışan kişilerin nitelikleri, örneğin yeni gelenlere öğretmenlik yapma yetenekleri ve yetkinlikleri.
• Projeye yeni eklenen kişilerin nitelikleri, örneğin yeni materyalleri öğrenme yetenekleri ve isteklilikleri.
• Projeye eklenen yeni kişilerin sayısı.
• Genel ekip büyüklüğü.
• Yeni kişilerin eklenmesinden önceki ve sonraki grup sosyal dinamiği.
• Grup üyelerinin iletişim kurması beklenen yollar.
• Ekip içindeki hiyerarşi ve karar alma süreci.
• Projede yer alan görevlerin türü ve özellikle bunların bölünebilme derecesi.
• Ek insan gücünün eklenme nedeni.
• Projeyi desteklemek için atılan, insan gücü eklemenin ötesinde adımlar (varsa).

Örneğin, bir makalede belirtildiği gibi:^[7]

Brooks Yasası, Özgür Yazılım bağlamında sorgulanmıştır: Büyük geliştirici ekipleri, yasanın aksine, günbegün artan iletişim kanallarına ihtiyaç duymamaktadır. Bu yasayı savunan kimseler, iletişim kanalları ihtiyacının oluşmama nedenini Özgür Yazılım sürecinin içsel özellikleriyle açıklamaktadır: Kodun yüksek modülerliği, geliştiricilerin diğer tüm katkıda bulunanlarla koordinasyon kurmasına gerek kalmadan ortak bölümler üzerinde çalışmasına yardımcı olmaktadır...

Bu makalede savunucuların iddiasının belirli sınırlamalar dahilinde doğru olduğu savunulmaktadır: KDE projesinin başlangıcında birkaç geliştirici, önemli miktarda iletişime ihtiyaç duymuştu. KDE'nin büyümesi, genel iletişim kanallarının sayısını önemli ölçüde azaltma ihtiyacını da beraberinde getirdi. Son olarak, şu anda 300 geliştiriciden oluşan bir kadro, geliştirici sayısının yalnızca 10 olduğu zamanki ile aynı miktarda iletişime ihtiyaç duymaktadır. Elde edilen sonucu Brooks Yasası'nın herhangi bir büyük Özgür Yazılım projesinin çekirdek geliştiricileri arasında geçerli olduğunu savunarak yorumluyoruz.

Bu uyarı, Brooks yasasının genelleştirilmiş versiyonu söz konusu olduğunda da geçerlidir. Örneğin, bir projeye para eklemenin projenin daha hızlı ilerlemesini sağlayıp sağlamayacağı, paranın ne için kullanılacağı gibi çok çeşitli faktörlere bağlıdır.

Brooks Yasasını Kullanmak

Brooks yasasından faydalanabilmek için incelikle bir projeye daha fazla kaynak eklemenin faydalı olacağı varsayımından kaçınmalısınız. Bunun yerine, kaynak eklemeniz gerekip gerekmediğini, gerekiyorsa ne kadar ve ne şekilde eklemeniz gerektiğini belirlemek için önce içinde bulunduğunuz durumu değerlendirmelisiniz.

Özellikle, kaynak eklemeden önce kendinize iki soru sormalısınız:

• Daha fazla kaynak eklemek projeye nasıl yardımcı olabilir?
• Daha fazla kaynak eklemek projeye nasıl zarar verebilir?

Daha sonra, bu soruların yanıtlarını hedefleriniz ışığında değerlendirmeli ve projeye daha fazla kaynak ekleyip eklemeyeceğinize ve nasıl ekleyeceğinize karar vermelisiniz. Bu karar aşamasında kaynak eklemenin istenen sonuçlara götürme açısından ne kadar etkili olacağını (son teslim tarihine kadar bitirme) ve kaynak israfını önleme açısından ne kadar verimli olacağını (geliştiricilerin gereksiz bürokrasi yerine işlerine odaklanması) düşünebilirsiniz.

Örneğin ana hedefiniz projeyi mümkün olduğunca hızlı bir şekilde tamamlamaksa ekip üyelerinizin bireysel üretkenliğinden fedakarlıkta bulunup bir bütün olarak ekibin tümünün üretkenliğini artırmak için daha fazla kişi eklemeyi düşünebilirsiniz. Yani 2 kişilik bir ekip %100 bireysel verimlilikle çalışıyorsa kümülatif verimlilikleri %200'e eşdeğerdir. Bir kişi daha eklemek bireysel verimliliği %80'e düşürür, ancak ekibin genel verimliliğini %240'a çıkarır.

Ayrıca kaynak ekleme kararının tek başına faydalı veya faydasız olarak ikili bir düzlemde değerlendirilmediğini unutmamalısınız. Yani elinizdeki tüm kaynakları eklemek verimsiz olsa bile, yalnızca bazı kaynakları eklemek verimli olabilir. Örneğin, bir yazılım projesine üç geliştirici eklemek proje verimini düşünebilir, ancak bir geliştirici eklemek verimi artırabilir.

Benzer şekilde, bir projeye kaynak eklemeye ek olarak veya kaynak eklemek yerine proje kapsamını değiştirmek veya teslim tarihini ertelemek gibi yöntemlerin de bazen tercih edildiğini unutmamalısınız.

Ne yapacağınıza karar vermeden önce bu tür bir analiz yapmak, Brooks yasasının her durumda geçerli olmadığını görmenize ve bir projeye kaynak eklemenin doğurduğu sorunları en aza indirmenin yollarını belirlemenize yardımcı olabilir. Örneğin yazılım geliştirme bağlamında eşli programlama gibi yöntemlerin iletişim sorunlarını azaltmada etkili olduğu görülmüştür, bu ve benzeri yöntemler de artan insan gücünden doğan bazı sorunların hafifletilmesine yardımcı olabilir.^{[8], [9]}

Böyle bir analiz aynı zamanda bir projenin mevcut yürütülme şeklinin değerlendirilmesinde ve kaynak kullanım veriminin belirlenmesinde de faydalı olabilir.

Son olarak, işyerinizde bir başka yetkili, bir hata olduğunu bildiğiniz halde daha fazla kaynak eklemekte ısrar ediyorsa, belirli kriterlere bağlı olarak yapabileceğiniz birkaç şey vardır:

• Bu kimseden kaynak ekleme gerekçelerini ve bu gerekçelerdeki kusurları açıklamalarını rica edin.
• Brooks yasası ve içinde bulunduğunuz duruma uygun örnekleri ile kaynak eklemenin neden kötü bir fikir olduğunu açıklayın.
• Projenin kapsamını veya son teslim tarihini değiştirmek gibi alternatif bir çözüm bulmasını sağlayın.
• Kaynak ekleme ile ilgili sorunları azaltmak için başlangıçta hedeflediklerinden daha az kaynak eklemeye ikna edin.
• Kaynak eklemeyi kabul edin ve daha fazla kaynak eklemenin olası sorunlarını en aza indirmeye çalışın.
• Görmezden gelin.
• İşe yaramayacağını bilseniz bile planlarına tamamen uyun.

Not: Brooks yasası çerçevesinde oluşan sorunları esprili bir yolla çözen Bermuda planı, bir şirketin programcılarının %90'ını bir tekneye bindirip Bermuda'ya göndererek kalan %10'un işi bitirmesinin daha sağlıklı olduğunu savunur.

Pexels

Ek Bilgiler

Brooks Yasasının Kökeni ve Tarihçesi

Brooks yasası, Amerikalı bilgisayar bilimcisi Fred Brooks tarafından 1975 tarihli "Mitik İş Ayı: Yazılım Mühendisliği Üzerine Denemeler" (İng: "The Mythical Man-Month: Essays on Software Engineering") adlı kitabında şu şekilde öne sürülmüştür:^[1]

Aşırı derecede basitleştirilmiş şekliyle Brooks Yasası şunu ifade eder:

Geç kalmış bir yazılım projesine insan gücü eklemek projeyi daha da geciktirir.

Yani bu iş ayı mitinin çözülmesidir. Bir projenin bitirileceği ay sayısı, dizgesel kısıtlamalarına bağlıdır. Maksimum personel sayısı ise bağımsız alt görevlerin sayısına bağlıdır. Bu iki değerin daha az personel ve daha fazla ay gibi bir kombinasyonuyla çeşitli takvimler oluşturulabilir (bunun tek riski ürünün eskimesidir). Ancak daha fazla adam ve daha az ay kullanarak uygulanabilir takvimler oluşturulamaz. Takvim zamanının yetersizliği nedeniyle ters giden yazılım projelerinin sayısı, diğer tüm nedenlerle ters giden projelerin toplamından daha fazladır.

Bu kitabın yayınlanma tarihinden bu yana Brooks yasası birçok eserde tartışılagelmiş ve yasayı test etmek için bazı empirik araştırmalar yapılmıştır. Örneğin konuyla ilgili bir çalışmada şu sözlere yer verilmektedir:^[10]

Çoğu yazılım şirketinin karşı karşıya olduğu ortak sorun, 'farklı yetenek ve becerilere sahip nispeten büyük insan gruplarının çevik ve yetenekli küçük ekipler gibi birlikte çalışmasının nasıl sağlanacağıdır'...

İlk olarak bir yazılım proje ekibi için maksimum büyüklüğün üretkenliği önemli ölçüde azalttığına dair güçlü kanıtlar bulguladık. İkinci olarak, daha büyük ekip boyutlarına yol açan iki tür karmaşıklık tespit ettik: yazılım ürününün mantıksal karmaşıklığı ve diğer yazılımlarla olan arayüzlerin sayısı.

Yazılım Sektöründe Brooks Yasası ve Linus Yasası

Linus yasası, "Yeterli sayıda göz ile bakıldığında çözülemeyecek sorun yoktur." atasözü ile özetlenir. Eric S. Raymond tarafından ilk olarak 1997 yılında bir makale olarak sunulan, 1999 yılında yayınlanan "Katedral ve Pazar" (İng: "The Cathedral and the Bazaar") adlı kitapta formüle edilmiştir. Raymond kitapta Linus yasası ve bu yasanın Brooks yasası ile ilişkisi hakkında şunları söylemektedir:^[11]

Linus doğrudan hata ayıklama ve geliştirmeye harcanan insan-saat sayısını, kodda istikrarsızlık ve herhangi bir ciddi hatanın çözülememesi takdirinde kullanıcı tabanının tükenmesini dahi göze alarak en üst düzeye çıkarmayı hedeflemekteydi. Linus'un bu düşünce biçimi şu şekilde özetlenebilirdi:

Yeterince geniş bir beta testçi ve ortak geliştirici tabanı sağlandığında neredeyse her sorun hızlı bir şekilde tanımlanacak ve birileri bu sorunların nasıl düzeltileceğini kolaylıkla bulacaktır.

Ya da, daha gayriresmi bir ifadeyle, 'Yeterli sayıda göz ile bakıldığında çözülemeyecek sorun yoktur.' Burada bu fenomene adını ben veriyorum, 'Linus Yasası.'

Benim orijinal formülasyonum her sorunun çözümünün 'birileri tarafından kolaylıkla görülebileceği' şeklindeydi. Linus, sorunu anlayan ve çözen kişinin mutlaka ya da genellikle sorunu ilk tanımlayan kişi olmadığı konusunu savundu. 'Birisi sorunu bulur,' dedi, 've bir başkası da sorun neymiş, onu anlar. Sorunu bulmanın daha büyük bir zorluk olduğunu da söyleyerek kayıtlara geçeceğim ki'...

Linus Yasasının temelinde katedral ve pazar inşaat tarzlarının arasındaki fark neyse o yatıyor. Katedral tarzı yazılım geliştirmede hata ve yazılım geliştirmeye ilişkin sorunlar genellikle aldatıcı, sinsi ve derin fenomenlerdir; ancak birkaç kişinin aylarca süren mesaisi sonucunda 'tamam, hepsini hallettik' diyecek özgüvene erişilebilir. Bundan ötürü yayınlama aralıkları açıktır, çok uzun süre heyecanla beklendikten sonra yayınlanan ürünler de bekleyenlerini kaçınılmaz bir şekilde hayal kırıklığına uğratır, zira mükemmel değildirler.

Öte yandan pazar tarzında hataların genellikle sığ fenomenler olduğunu, ya da her bir sürümü didik didik inceleyen bin kadar hevesli ortak geliştiriciyle sığ fenomenlere dönüştüğünü varsayarsınız. Buna göre, daha fazla düzeltme almak için sık sık yeni sürümler yayınlarsınız ve bunun da faydalı bir yan etkisi bir hata şu kapıdan çıkıp dünyaya karışsa bile kaybedecek şeyiniz pek az olur.

İşte bu kadar. Yeter. Eğer 'Linus Yasası' yanlış olsaydı Linux kernel kadar karmaşık olan ve bu kernel kadar çok kimse tarafından hacklenen herhangi bir sistem, bir noktada öngörülemeyen kötü etkileşimlerin ve keşfedilmemiş 'derin' hataların ağırlığı altında çöküp giderdi. Öte yandan, eğer yasa doğruysa, Linux'un görece hatasızlığını ve aylar hatta yıllar süren kesintisiz çalışma sürelerini açıklamak için yeterlidir.

Linus yasasının bazen Brooks yasası ile çeliştiği dile getirilir. Raymond bu çelişkiyi de kitabında irdelemiştir:^[11]

...Böylece her iki tarafın da kaynak kodu farkındalığı, hem iyi iletişimi, hem de beta testçinin raporladıkları ile çekirdek geliştiricinin/geliştiricilerin bildikleri arasındaki sinerjiyi büyük ölçüde artırır. Bu da çok sayıda ortak olsa bile çekirdek geliştiricilerin zamanının iyi kullanılacağı anlamına gelir.

Açık kaynak yönteminin geliştiricilerin zamanını iyi kullanmalarını sağlayan bir diğer özelliği de tipik açık kaynak projelerinin iletişim yapısıdır. Daha önce 'çekirdek geliştirici' (İng: "core developer) terimini kullanmıştım; bu, proje çekirdeği (genellikle oldukça küçüktür; tek bir çekirdek geliştirici yaygındır ve bir ila üç tipiktir) ile beta testçiler ve mevcut katkıda bulunanlardan oluşan proje halesi (genellikle sayıları yüzlerle ifade edilir) arasındaki ayrımı yansıtır.

Geleneksel yazılım geliştirme organizasyonunun ele aldığı temel sorun Brooks Yasasıdır: 'Geç kalmış bir projeye daha fazla programcı eklemek projenin daha da gecikmesine sebep olur'. Daha genel olarak Brooks Yasası, bir projenin karmaşıklığının ve iletişim maliyetlerinin geliştirici sayısının karesi ile arttığını, yapılan işin ise yalnızca doğrusal olarak arttığını öngörür.

Brooks Yasası, hataların farklı insanlar tarafından yazılan kodlar arasındaki arayüzlerde kümelenme eğiliminde olduğu ve bir projedeki iletişim/koordinasyon ek yükünün insanlar arasındaki arayüzlerin sayısıyla artma eğiliminde olduğu deneyimlerine dayanmaktadır. Bu nedenle sorunlar, geliştiriciler arasındaki iletişim yollarının sayısıyla ölçeklenir ve bu da geliştirici sayısının karesi olarak (N*(N-1)/2 formülüne göre, burada N geliştirici sayısıdır) hesaplanır.

Brooks Yasası analizi (ve bunun sonucunda ortaya çıkan geliştirme gruplarında büyük sayılara yönelik duyulan korku), proje iletişim yapısının tam manasıyla bir 'grafik' olduğu, herkesin herkesle konuştuğu bir gizli varsayıma dayanmaktadır. Ancak açık kaynaklı projelerde hale içinde yer alan geliştiriciler, aslında birbirinden farklı paralel alt görevler üzerinde çalışır ve birbirleriyle çok az etkileşime girer; kod değişiklikleri ve hata raporları çekirdek grup üzerinden akar ve yalnızca bu küçük çekirdek grup içinde Brooks'un öngördüğü bütün maliyeti biz sırtlanırız...

Raymond şunları da eklemektedir:^[11]

John Hasler, çabaların tekrarlanmasının (belirli bir kodun tekrar yazılmasının) açık kaynak geliştirme konusunda net bir problem yaratmaması gerçeğine ilginç bir açıklama getirmiştir. Benim 'Hasler Yasası' olarak adlandıracağım açıklamasının temelinde şu vardır: mükerrer çalışmaların maliyetleri, ekip büyüklüğüne göre ikincil dereceden büyüme eğilimindedir; yani mükerrerliği ortadan kaldırmak için gerekli olan planlama ve yönetim ek yüküne kıyasla daha yavaş büyür.

Bu iddia temelinde Brooks Yasası ile çelişmemektedir. Toplam karmaşıklık ek yükünün ve hatalara karşı savunmasızlığın ekip büyüklüğünün karesiyle ölçeklendiği, ancak mükerrer işlerden kaynaklanan maliyetlerin yine de daha yavaş büyüyen özel bir durum olduğu bir durum olabilir. Bunun gerçekleşebilmesini sağlayacak makul yöntemler bulmak zor değildir; farklı geliştiricilerin kodları arasında mükerrer çalışmayı önleyecek işlevsel sınırlar üzerinde anlaşmaya varmanın, çoğu hatanın altında yatan tüm sistemdeki planlanmamış kötü etkileşim türlerini önlemekten çok daha kolay olduğu şüphe götürmez bir gerçektir.

Linus Yasası ve Hasler Yasasının kombinasyonu, yazılım projelerinde aslında üç kritik boyut rejimi olduğunu göstermektedir. Küçük projelerde (bir ila en fazla üç geliştirici) bir lider programcı seçmekten daha ayrıntılı bir yönetim yapısına gerek yoktur. Bunun üzerinde, geleneksel yönetimin maliyetinin nispeten düşük olduğu, dolayısıyla mükerrer çabadan kaçınma, hata takibi ve ayrıntıların gözden kaçırılmadığından emin olmak için dikkatin sağladığı faydaların aslında net olarak pozitif olduğu bir ara aralık vardır.

Ancak bunun ötesinde, Linus Yasası ve Hasler Yasasının birleşimi, geleneksel yönetimin maliyetlerinin ve sorunlarının çaba tekrarının yaratmasının beklendiği maliyetten çok daha hızlı arttığı büyük bir proje aralığı olduğunu göstermektedir. Bu maliyetlerin en önemlisi, (gördüğümüz gibi) hataların ve ayrıntıların gözden kaçmamasını sağlamada geleneksel yönetimden çok daha başarılı bir yöntem olan çoklu göz etkisinden yararlanmaya yönelik yapısal yetersizliktir. Dolayısıyla büyük projelerde bu yasaların birleşimi, geleneksel yönetimin net getirisini sıfıra indirmektedir.

Wikimedia Commons

Bu iki kavram arasındaki ilişkiye dair bazı empirik araştırmalar da mevcuttur. Örneğin bir çalışmada ücretsiz açık kaynaklı yazılım projelerinden (FOSS) oluşan geniş bir koleksiyon incelenmiş ve üç potansiyel hipotez test edilmiştir:^[12]

• Linus Yasası Hipotezi: Daha büyük geliştirme ekiplerine sahip FOSS projeleri daha başarılı olacaktır (Linus Yasası).
• Brooks Yasası Hipotezi: Daha büyük ekiplere sahip FOSS projeleri, FOSS gelişimini engelleyecek nitelikte ek koordinasyon maliyetleriyle karşılaşacaktır. Sonuç olarak, daha az başarılı olacaklardır (Olson ve Brooks).
• "Çekirdek Ekip" Hipotezi: Geliştirme ekibinin büyüklüğünün FOSS proje başarısı üzerinde herhangi bir etkisi olmayacaktır, çünkü çekirdek geliştirici grupları neredeyse her zaman küçük ekiplerdir (Zawinski).

Sonuçlar, projedeki geliştirici sayısı arttıkça projenin başarılı olma olasılığının da arttığını göstermiştir. Ancak bu konuda iki önemli unsurun akılda tutulması gerekmektedir:

Birincisi, bu çalışmaya dayanarak bir neden sonuç bağı kurmak zordur. Araştırmacıların kendilerinin de belirttiği gibi:^[12]

Bulgularımız bir tür tavuk-yumurta sorunu yaratıyor. Daha fazla geliştirici bir projenin daha başarılı olmasını sağlar mı? Yoksa başarılı projeler, kısmen bazı programcıları katılmaya iten ekonomik motivasyonlar (örneğin, geniş bir topluluğa programlama becerilerini kanıtlamak, başkalarının programlarını okuyarak ders çıkarmak ve akran değerlendirmesinden faydalanmak) sayesinde daha fazla geliştiriciyi mi çekmektedir? Bu soruyu elimizdeki veri setiyle yanıtlayamayız, çünkü bu veri seti genellikle zaman içinde bir noktayı temsil etmektedir...

İkinci olarak, Brooks yasası artan insan gücünün potansiyel dezavantajlarına odaklanırken, Linus yasası potansiyel avantajlarına odaklanmaktadır. Bu yasalar çelişkili veya birbirini dışlayan yasalar değildir. Örneğin bir projeye daha fazla insan eklenmesinin projeyi geciktirdiği (dolayısıyla Brooks yasasını işlettiği), ancak aynı zamanda uzun süredir devam eden bazı hataların çözülmesine yardımcı olduğu (dolayısıyla Linus yasasını işlettiği) durumlar da söz konusudur. Dahası, bu iki yasa genel olarak farklı -ancak birbiriyle ilişkili- bağlamlar için geçerlidir ve farklı insan gücü türlerini içerir.

Özet ve Sonuçlar

• Brooks yasası, "geç kalmış bir yazılım projesine insan gücü eklemenin projeyi daha da geciktirdiği" gözlemidir.
• Genel kapsamıyla ele alındığında bu ilke, çeşitli proje türleri söz konusu olduğunda bir bileşene daha fazla kaynak, özellikle de daha fazla insan eklemenin genellikle yararsız ve hatta ters etki yarattığını ifade eder.
• Brooks yasası, projeye yeni eklenen insanları eğitmek için gereken zaman, daha fazla personel sebebiyle artan iletişim yükü ve belirli görevlerin sınırlı bölünebilirliği gibi çeşitli nedenlerle açıklanmaktadır.
• Brooks yasası yalnızca bazı durumlarda geçerlidir ve geçerli olduğu durumlar ekip üyelerinin nitelikleri, ekip büyüklüğü, grup dinamikleri, ilgili görev türleri ve projenin mevcut durumu gibi çeşitli faktörlere bağlıdır.
• Brooks yasasından faydalanabilmek için bir projeye daha fazla kaynak eklemenin kesinlikle faydalı olacağını varsaymaktan kaçınmalısınız. Bunun yerine kaynak eklemeniz gerekip gerekmediğini, gerekiyorsa ne kadar ve ne şekilde eklemeniz gerektiğini belirlemek için bir durum değerlendirmesi yapmalısınız.