Paylaşım Yap
Tüm Reklamları Kapat
Tüm Reklamları Kapat

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

Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir! The Mycenaean
25 dakika
1,554
  • İnsan Kaynakları Yönetimi
  • Uygulamalı Psikoloji
Evrim Ağacı Akademi: Bilime Dayalı Kişisel Gelişim Yazı Dizisi

Bu yazı, Bilime Dayalı Kişisel Gelişim yazı dizisinin 31. yazısıdır. Bu yazı dizisini okumaya, serinin 1. yazısı olan "Stanford Marshmallow Deneyi Nedir? Çocukken Sergilenen Öz Kontrol, Yetişkinlikte Başarıyı Nasıl Etkiler?" başlıklı makalemizden başlamanızı öneririz.

Yazı dizisi içindeki ilerleyişinizi kaydetmek için veya kayıt olun.

EA Akademi Hakkında Bilgi Al

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.

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

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.

Evrim Ağacı'ndan Mesaj

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.

Tüm Reklamları Kapat

İş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.

Tüm Reklamları Kapat

Üçü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:

Tüm Reklamları Kapat

Agora Bilim Pazarı
Köpeklerin Sohbeti

Talihsiz bir evlilik yüzünden hastaneye düşen bir teğmen hasta yatağında yatarken sokakta iki kişinin konuştuğunu duyar. Sohbetin çekiciliğine kendini iyice kaptıran teğmen konuşanların aslında hastanenin bekçi köpekleri olduğunu anlar ve bu mucizevi sohbeti kağıda aktarır. Bir süreliğine konuşma kabiliyeti kazanan iki köpek başlarından geçenleri anlatırken insanlığın derin mevzularına değinirler: ahlak, yozlaşma, dedikodu, haset, talih, onur, sinsilik, tahakküm… Cervantes’in yaşadığı dönem ve ülke üzerine yoğun bir hiciv içeren bu uzun öyküsü, bütün bir insanlık tarihinin (ve muhtemelen geleceğimizin de) güzel bir eleştirisine dönüşüyor.

Devamını Göster
₺33.00
Köpeklerin Sohbeti

  • 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.

Tüm Reklamları Kapat

İç 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...

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

Ö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]

Tüm Reklamları Kapat

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]

Tüm Reklamları Kapat

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]

Tüm Reklamları Kapat

Ç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:

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

Ö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.

Tüm Reklamları Kapat

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...

Tüm Reklamları Kapat

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.

Tüm Reklamları Kapat

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.
Alıntı Yap
Okundu Olarak İşaretle
Evrim Ağacı Akademi: Bilime Dayalı Kişisel Gelişim Yazı Dizisi

Bu yazı, Bilime Dayalı Kişisel Gelişim yazı dizisinin 31. yazısıdır. Bu yazı dizisini okumaya, serinin 1. yazısı olan "Stanford Marshmallow Deneyi Nedir? Çocukken Sergilenen Öz Kontrol, Yetişkinlikte Başarıyı Nasıl Etkiler?" başlıklı makalemizden başlamanızı öneririz.

Yazı dizisi içindeki ilerleyişinizi kaydetmek için veya kayıt olun.

EA Akademi Hakkında Bilgi Al
23
Paylaş
Sonra Oku
Notlarım
Yazdır / PDF Olarak Kaydet
Bize Ulaş
Yukarı Zıpla

İçeriklerimizin bilimsel gerçekleri doğru bir şekilde yansıtması için en üst düzey çabayı gösteriyoruz. Gözünüze doğru gelmeyen bir şey varsa, mümkünse güvenilir kaynaklarınızla birlikte bize ulaşın!

Bu içeriğimizle ilgili bir sorunuz mu var? Buraya tıklayarak sorabilirsiniz.

Soru & Cevap Platformuna Git
Bu İçerik Size Ne Hissettirdi?
  • Tebrikler! 3
  • Mmm... Çok sapyoseksüel! 1
  • Güldürdü 1
  • Umut Verici! 1
  • Merak Uyandırıcı! 1
  • Muhteşem! 0
  • Bilim Budur! 0
  • İnanılmaz 0
  • Üzücü! 0
  • Grrr... *@$# 0
  • İğrenç! 0
  • Korkutucu! 0
Kaynaklar ve İleri Okuma
Tüm Reklamları Kapat

Evrim Ağacı'na her ay sadece 1 kahve ısmarlayarak destek olmak ister misiniz?

Şu iki siteden birini kullanarak şimdi destek olabilirsiniz:

kreosus.com/evrimagaci | patreon.com/evrimagaci

Çıktı Bilgisi: Bu sayfa, Evrim Ağacı yazdırma aracı kullanılarak 27/01/2023 00:51:07 tarihinde oluşturulmuştur. Evrim Ağacı'ndaki içeriklerin tamamı, birden fazla editör tarafından, durmaksızın elden geçirilmekte, güncellenmekte ve geliştirilmektedir. Dolayısıyla bu çıktının alındığı tarihten sonra yapılan güncellemeleri görmek ve bu içeriğin en güncel halini okumak için lütfen şu adrese gidiniz: https://evrimagaci.org/s/13221

İçerik Kullanım İzinleri: Evrim Ağacı'ndaki yazılı içerikler orijinallerine hiçbir şekilde dokunulmadığı müddetçe izin alınmaksızın paylaşılabilir, kopyalanabilir, yapıştırılabilir, çoğaltılabilir, basılabilir, dağıtılabilir, yayılabilir, alıntılanabilir. Ancak bu içeriklerin hiçbiri izin alınmaksızın değiştirilemez ve değiştirilmiş halleri Evrim Ağacı'na aitmiş gibi sunulamaz. Benzer şekilde, içeriklerin hiçbiri, söz konusu içeriğin açıkça belirtilmiş yazarlarından ve Evrim Ağacı'ndan başkasına aitmiş gibi sunulamaz. Bu sayfa izin alınmaksızın düzenlenemez, Evrim Ağacı logosu, yazar/editör bilgileri ve içeriğin diğer kısımları izin alınmaksızın değiştirilemez veya kaldırılamaz.

Tüm Reklamları Kapat
Size Özel (Beta)
İçerikler
Sosyal
Kütle
Eğilim
Enzim
Tüyler
Sağlık Bakanlığı
Vejetaryen
Dalga
Amerika
Sahte
Genetik Değişim
Evren
Arı
Beslenme Bilimi
Köpekbalığı
Balık Çeşitliliği
Öne Çıkan
Analiz
Manyetik
Moleküler Biyoloji
Kan Hastalıkları
Mikoloji
Stephen Hawking
Doğa Yasası
Güve
Gazetecilik
Aklımdan Geçen
Komünite Seç
Aklımdan Geçen
Fark Ettim ki...
Bugün Öğrendim ki...
İşe Yarar İpucu
Bilim Haberleri
Hikaye Fikri
Video Konu Önerisi
Başlık
Bugün Türkiye'de bilime ve bilim okuryazarlığına neler katacaksın?
Bağlantı
Kurallar
Komünite Kuralları
Bu komünite, aklınızdan geçen düşünceleri Evrim Ağacı ailesiyle paylaşabilmeniz içindir. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu komünitenin ek kurallarına da uymanız gerekmektedir.
1
Bilim kimliğinizi önceleyin.
Evrim Ağacı bir bilim platformudur. Dolayısıyla aklınızdan geçen her şeyden ziyade, bilim veya yaşamla ilgili olabilecek düşüncelerinizle ilgileniyoruz.
2
Propaganda ve baskı amaçlı kullanmayın.
Herkesin aklından her şey geçebilir; fakat bu platformun amacı, insanların belli ideolojiler için propaganda yapmaları veya başkaları üzerinde baskı kurma amacıyla geliştirilmemiştir. Paylaştığınız fikirlerin değer kattığından emin olun.
3
Gerilim yaratmayın.
Gerilim, tersleme, tahrik, taciz, alay, dedikodu, trollük, vurdumduymazlık, duyarsızlık, ırkçılık, bağnazlık, nefret söylemi, azınlıklara saldırı, fanatizm, holiganlık, sloganlar yasaktır.
4
Değer katın; hassas konulardan ve öznel yoruma açık alanlardan uzak durun.
Bu komünitenin amacı okurlara hayatla ilgili keyifli farkındalıklar yaşatabilmektir. Din, politika, spor, aktüel konular gibi anlık tepkilere neden olabilecek konulardaki tespitlerden kaçının. Ayrıca aklınızdan geçenlerin Türkiye’deki bilim komünitesine değer katması beklenmektedir.
5
Cevap hakkı doğurmayın.
Bu platformda cevap veya yorum sistemi bulunmamaktadır. Dolayısıyla aklınızdan geçenlerin, tespit edilebilir kişilere cevap hakkı doğurmadığından emin olun.
Gönder
Ekle
Soru Sor
Daha Fazla İçerik Göster
Evrim Ağacı'na Destek Ol
Evrim Ağacı'nın %100 okur destekli bir bilim platformu olduğunu biliyor muydunuz? Evrim Ağacı'nın maddi destekçileri arasına katılarak Türkiye'de bilimin yayılmasına güç katmak için hemen buraya tıklayın.
Popüler Yazılar
30 gün
90 gün
1 yıl
EA Akademi
Evrim Ağacı Akademi (ya da kısaca EA Akademi), 2010 yılından beri ürettiğimiz makalelerden oluşan ve kendi kendinizi bilimin çeşitli dallarında eğitebileceğiniz bir çevirim içi eğitim girişimi! Evrim Ağacı Akademi'yi buraya tıklayarak görebilirsiniz. Daha fazla bilgi için buraya tıklayın.
Etkinlik & İlan
Bilim ile ilgili bir etkinlik mi düzenliyorsunuz? Yoksa bilim insanlarını veya bilimseverleri ilgilendiren bir iş, staj, çalıştay, makale çağrısı vb. bir duyurunuz mu var? Etkinlik & İlan Platformumuzda paylaşın, milyonlarca bilimsevere ulaşsın.
Podcast
Evrim Ağacı'nın birçok içeriğinin profesyonel ses sanatçıları tarafından seslendirildiğini biliyor muydunuz? Bunların hepsini Podcast Platformumuzda dinleyebilirsiniz. Ayrıca Spotify, iTunes, Google Podcast ve YouTube bağlantılarını da bir arada bulabilirsiniz.
Yazı Geçmişi
Okuma Geçmişi
Notlarım
İlerleme Durumunu Güncelle
Okudum
Sonra Oku
Not Ekle
Kaldığım Yeri İşaretle
Göz Attım

Evrim Ağacı tarafından otomatik olarak takip edilen işlemleri istediğin zaman durdurabilirsin.
[Site ayalarına git...]

Filtrele
Listele
Bu yazıdaki hareketlerin
Devamını Göster
Filtrele
Listele
Tüm Okuma Geçmişin
Devamını Göster
0/10000
Alıntı Yap
Evrim Ağacı Formatı
APA7
MLA9
Chicago
I. Shatz, et al. Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir!. (7 Kasım 2022). Alındığı Tarih: 27 Ocak 2023. Alındığı Yer: https://evrimagaci.org/s/13221
Shatz, I., Karagözoğlu, M. (2022, November 07). Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir!. Evrim Ağacı. Retrieved January 27, 2023. from https://evrimagaci.org/s/13221
I. Shatz, et al. “Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir!.” Edited by Mert Karagözoğlu. Evrim Ağacı, 07 Nov. 2022, https://evrimagaci.org/s/13221.
Shatz, Itamar. Karagözoğlu, Mert. “Brooks Yasası: Geciken İşi Bir An Önce Bitirmek İçin Personel Atamak, İşi Daha da Fazla Geciktirebilir!.” Edited by Mert Karagözoğlu. Evrim Ağacı, November 07, 2022. https://evrimagaci.org/s/13221.

Göster

Şifremi unuttum Üyelik Aktivasyonu

Göster

Şifrenizi mi unuttunuz? Lütfen e-posta adresinizi giriniz. E-posta adresinize şifrenizi sıfırlamak için bir bağlantı gönderilecektir.

Geri dön

Eğer aktivasyon kodunu almadıysanız lütfen e-posta adresinizi giriniz. Üyeliğinizi aktive etmek için e-posta adresinize bir bağlantı gönderilecektir.

Geri dön

Close
Geri Bildirim Gönder
Paylaş
Reklamsız Deneyim

Evrim Ağacı'ndaki reklamları, bütçenize uygun bir şekilde, kendi seçtiğiniz bir süre boyunca kapatabilirsiniz. Tek yapmanız gereken, kaç ay boyunca kapatmak istediğinizi aşağıdaki kutuya girip tek seferlik ödemenizi tamamlamak:

10₺/ay
x
ay
= 30
3 Aylık Reklamsız Deneyimi Başlat
Evrim Ağacı'nda ücretsiz üyelik oluşturan ve sitemizi üye girişi yaparak kullanan kullanıcılarımızdaki reklamların %50 daha az olduğunu, Kreosus/Patreon/YouTube destekçilerimizinse sitemizi tamamen reklamsız kullanabildiğini biliyor muydunuz? Size uygun seçeneği aşağıdan seçebilirsiniz:
Evrim Ağacı Destekçilerine Katıl
Zaten Kreosus/Patreon/Youtube Destekçisiyim
Reklamsız Deneyim
Kreosus

Kreosus'ta her 10₺'lik destek, 1 aylık reklamsız deneyime karşılık geliyor. Bu sayede, tek seferlik destekçilerimiz de, aylık destekçilerimiz de toplam destekleriyle doğru orantılı bir süre boyunca reklamsız deneyim elde edebiliyorlar.

Kreosus destekçilerimizin reklamsız deneyimi, destek olmaya başladıkları anda devreye girmektedir ve ek bir işleme gerek yoktur.

Patreon

Patreon destekçilerimiz, destek miktarından bağımsız olarak, Evrim Ağacı'na destek oldukları süre boyunca reklamsız deneyime erişmeyi sürdürebiliyorlar.

Patreon destekçilerimizin Patreon ile ilişkili e-posta hesapları, Evrim Ağacı'ndaki üyelik e-postaları ile birebir aynı olmalıdır. Patreon destekçilerimizin reklamsız deneyiminin devreye girmesi 24 saat alabilmektedir.

YouTube

YouTube destekçilerimizin hepsi otomatik olarak reklamsız deneyime şimdilik erişemiyorlar ve şu anda, YouTube üzerinden her destek seviyesine reklamsız deneyim ayrıcalığını sunamamaktayız. YouTube Destek Sistemi üzerinde sunulan farklı seviyelerin açıklamalarını okuyarak, hangi ayrıcalıklara erişebileceğinizi öğrenebilirsiniz.

Eğer seçtiğiniz seviye reklamsız deneyim ayrıcalığı sunuyorsa, destek olduktan sonra YouTube tarafından gösterilecek olan bağlantıdaki formu doldurarak reklamsız deneyime erişebilirsiniz. YouTube destekçilerimizin reklamsız deneyiminin devreye girmesi, formu doldurduktan sonra 24 saat alabilmektedir.

Diğer Platformlar

Bu 3 platform haricinde destek olan destekçilerimize ne yazık ki reklamsız deneyim ayrıcalığını sunamamaktayız. Destekleriniz sayesinde sistemlerimizi geliştirmeyi sürdürüyoruz ve umuyoruz bu ayrıcalıkları zamanla genişletebileceğiz.

Giriş yapmayı unutmayın!

Reklamsız deneyim için, maddi desteğiniz ile ilişkilendirilmiş olan Evrim Ağacı hesabınıza yapmanız gerekmektedir. Giriş yapmadığınız takdirde reklamları görmeye devam edeceksinizdir.

Destek Ol

Devamını Oku
Evrim Ağacı Uygulamasını
İndir
Chromium Tabanlı Mobil Tarayıcılar (Chrome, Edge, Brave vb.)
İlk birkaç girişinizde zaten tarayıcınız size uygulamamızı indirmeyi önerecek. Önerideki tuşa tıklayarak uygulamamızı kurabilirsiniz. Bu öneriyi, yukarıdaki videoda görebilirsiniz. Eğer bu öneri artık gözükmüyorsa, Ayarlar/Seçenekler (⋮) ikonuna tıklayıp, Uygulamayı Yükle seçeneğini kullanabilirsiniz.
Chromium Tabanlı Masaüstü Tarayıcılar (Chrome, Edge, Brave vb.)
Yeni uygulamamızı kurmak için tarayıcı çubuğundaki kurulum tuşuna tıklayın. "Yükle" (Install) tuşuna basarak kurulumu tamamlayın. Dilerseniz, Evrim Ağacı İleri Web Uygulaması'nı görev çubuğunuza sabitleyin. Uygulama logosuna sağ tıklayıp, "Görev Çubuğuna Sabitle" seçeneğine tıklayabilirsiniz. Eğer bu seçenek gözükmüyorsa, tarayıcının Ayarlar/Seçenekler (⋮) ikonuna tıklayıp, Uygulamayı Yükle seçeneğini kullanabilirsiniz.
Safari Mobil Uygulama
Sırasıyla Paylaş -> Ana Ekrana Ekle -> Ekle tuşlarına basarak yeni mobil uygulamamızı kurabilirsiniz. Bu basamakları görmek için yukarıdaki videoyu izleyebilirsiniz.

Daha fazla bilgi almak için tıklayın

Önizleme
Görseli Kaydet
Sıfırla
Vazgeç
Ara
Moderatöre Bildir

Raporlama sisteminin amacı, platformu uygunsuz biçimde kullananların önüne geçmektir. Lütfen bir içeriği, sadece düşük kaliteli olduğunu veya soruya cevap olmadığını düşündüğünüz raporlamayınız; bu raporlar kabul edilmeyecektir. Bunun yerine daha kaliteli cevapları kendiniz girmeye çalışın veya size sunulan (oylama gibi) diğer araçlar ile daha kaliteli cevaplara teşvik edin. Kalitesiz bulduğunuz içerikleri eleyebileceğiniz, kalitelileri daha ön plana çıkarabileceğiniz yeni araçlar geliştirmekteyiz.

Öncül Ekle
Sonuç Ekle
Soru Sor
Aşağıdaki "Soru" kutusunu sadece soru sormak için kullanınız. Bu kutuya soru formatında olmayan hiçbir cümle girmeyiniz. Sorunuzla ilgili ek bilgiler vermek isterseniz, "Açıklama" kısmına girebilirsiniz. Soru kısmının soru cümlesi haricindeki kullanımları sorunuzun silinmesine ve UP kaybetmenize neden olabilir.
Görsel Ekle
Kurallar
Platform Kuralları
Bu platform, aklınıza takılan soruları sorabilmeniz ve diğerlerinin sorularını yanıtlayabilmeniz içindir. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu platformun ek kurallarına da uymanız gerekmektedir.
1
Gerçekten soru sorun, imâdan ve yüklü sorulardan kaçının.
Sorularınızın amacı nesnel olarak gerçeği öğrenmek veya fikir almak olmalıdır. Şahsi kanaatinizle ilgili mesaj vermek için kullanmayın; yüklü soru sormayın.
2
Bilim kimliğinizi kullanın.
Evrim Ağacı bir bilim platformudur. Dolayısıyla sorular ve cevaplar, bilimsel perspektifi yansıtmalıdır. Geçerli bilimsel kaynaklarla doğrulanamayan bilgiler veya reklamlar silinebilir.
3
Düzgün ve insanca iletişim kurun.
Gerilim, tersleme, tahrik, taciz, alay, dedikodu, trollük, vurdumduymazlık, duyarsızlık, ırkçılık, bağnazlık, nefret söylemi, azınlıklara saldırı, fanatizm, holiganlık, sloganlar yasaktır.
4
Sahtebilimi desteklemek yasaktır.
Sahtebilim kategorisi altında konuyla ilgili sorular sorabilirsiniz; ancak bilimsel geçerliliği bulunmayan sahtebilim konularını destekleyen sorular veya cevaplar paylaşmayın.
5
Türkçeyi düzgün kullanın.
Şair olmanızı beklemiyoruz; ancak yazdığınız içeriğin anlaşılır olması ve temel düzeyde yazım ve dil bilgisi kurallarına uyması gerekmektedir.
Soru Ara
Aradığınız soruyu bulamadıysanız buraya tıklayarak sorabilirsiniz.
Alıntı Ekle
Eser Ekle
Kurallar
Komünite Kuralları
Bu komünite, fark edildiğinde ufku genişleten tespitler içindir. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu komünitenin ek kurallarına da uymanız gerekmektedir.
1
Formu olabildiğince eksiksiz doldurun.
Girdiğiniz sözün/alıntının kaynağı ne kadar açıksa o kadar iyi. Açıklama kısmına kitabın sayfa sayısını veya filmin saat/dakika/saniye bilgisini girebilirsiniz.
2
Anonimden kaçının.
Bazı sözler/alıntılar anonim olabilir. Fakat sözün anonimliğini doğrulamaksızın, bilmediğiniz her söze/alıntıya anonim yazmayın. Bu tür girdiler silinebilir.
3
Kaynağı araştırın ve sorgulayın.
Sayısız söz/alıntı, gerçekte o sözü hiçbir zaman söylememiş/yazmamış kişilere, hatalı bir şekilde atfediliyor. Paylaşımınızın site geneline yayılabilmesi için kaliteli kaynaklar kullanın ve kaynaklarınızı sorgulayın.
4
Ofansif ve entelektüel düşünceden uzak sözler yasaktır.
Gerilim, tersleme, tahrik, taciz, alay, dedikodu, trollük, vurdumduymazlık, duyarsızlık, ırkçılık, bağnazlık, nefret söylemi, azınlıklara saldırı, fanatizm, holiganlık, sloganlar yasaktır.
5
Sözlerinizi tırnak (") içine almayın.
Sistemimiz formatı otomatik olarak ayarlayacaktır.
Gönder
Tavsiye Et
Aşağıdaki kutuya, [ESER ADI] isimli [KİTABI/FİLMİ] neden tavsiye ettiğini girebilirsin. Ne kadar detaylı ve kapsamlı bir analiz yaparsan, bu eseri [OKUMAK/İZLEMEK] isteyenleri o kadar doğru ve fazla bilgilendirmiş olacaksın. Tavsiyenin sadece negatif içerikte olamayacağını, eğer bu sistemi kullanıyorsan tavsiye ettiğin içeriğin pozitif taraflarından bahsetmek zorunda olduğunu lütfen unutma. Yapıcı eleştiri hakkında daha fazla bilgi almak için burayı okuyabilirsin.
Kurallar
Platform Kuralları
Bu platform; okuduğunuz kitaplara, izlediğiniz filmlere/belgesellere veya takip ettiğiniz YouTube kanallarına yönelik tavsiylerinizi ve/veya yapıcı eleştirel fikirlerinizi girebilmeniz içindir. Tavsiye etmek istediğiniz eseri bulamazsanız, buradan yeni bir kayıt oluşturabilirsiniz. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu platformun ek kurallarına da uymanız gerekmektedir.
1
Önceliğimiz pozitif tavsiyelerdir.
Bu platformu, beğenmediğiniz eserleri yermek için değil, beğendiğiniz eserleri başkalarına tanıtmak için kullanmaya öncelik veriniz. Sadece negatif girdileri olduğu tespit edilenler platformdan geçici veya kalıcı olarak engellenebilirler.
2
Tavsiyenizin içeriği sadece negatif olamaz.
Tavsiye yazdığınız eserleri olabildiğince objektif bir gözlükle anlatmanız beklenmektedir. Dolayısıyla bir eseri beğenmediyseniz bile, tavsiyenizde eserin pozitif taraflarından da bahsetmeniz gerekmektedir.
3
Negatif eleştiriler yapıcı olmak zorundadır.
Eğer tavsiyenizin ana tonu negatif olacaksa, tüm eleştirileriniz yapıcı nitelikte olmak zorundadır. Yapıcı eleştiri kurallarını buradan öğrenebilirsiniz. Yapıcı bir tarafı olmayan veya tamamen yıkıcı içerikte olan eleştiriler silinebilir ve yazarlar geçici veya kalıcı olarak engellenebilirler.
4
Düzgün ve insanca iletişim kurun.
Gerilim, tersleme, tahrik, taciz, alay, dedikodu, trollük, vurdumduymazlık, duyarsızlık, ırkçılık, bağnazlık, nefret söylemi, azınlıklara saldırı, fanatizm, holiganlık, sloganlar yasaktır.
5
Türkçeyi düzgün kullanın.
Şair olmanızı beklemiyoruz; ancak yazdığınız içeriğin anlaşılır olması ve temel düzeyde yazım ve dil bilgisi kurallarına uyması gerekmektedir.
Eser Ara
Aradığınız eseri bulamadıysanız buraya tıklayarak ekleyebilirsiniz.
Tür Ekle
Üst Takson Seç
Kurallar
Komünite Kuralları
Bu platform, yaşamış ve yaşayan bütün türleri filogenetik olarak sınıflandırdığımız ve tanıttığımız Yaşam Ağacı projemize, henüz girilmemiş taksonları girebilmeniz için geliştirdiğimiz bir platformdur. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu komünitenin ek kurallarına da uymanız gerekmektedir.
1
Takson adlarını doğru yazdığınızdan emin olun.
Taksonların sadece ilk harfleri büyük yazılmalıdır. Latince tür adlarında, cins adının ilk harfi büyük, diğer bütün harfler küçük olmalıdır (Örn: Canis lupus domesticus). Türkçe adlarda da sadece ilk harf büyük yazılmalıdır (Örn: Evcil köpek).
2
Taksonlar arası bağlantıları doğru girin.
Girdiğiniz taksonun üst taksonunu girmeniz zorunludur. Eğer üst takson yoksa, mümkün olduğunca öncelikle üst taksonları girmeye çalışın; sonrasında daha alt taksonları girin.
3
Birden fazla kaynaktan kontrol edin.
Mümkün olduğunca ezbere iş yapmayın, girdiğiniz taksonların isimlerinin birden fazla kaynaktan kontrol edin. Alternatif (sinonim) takson adlarını girmeyi unutmayın.
4
Tekrara düşmeyin.
Aynı taksonu birden fazla defa girmediğinizden emin olun. Otomatik tamamlama sistemimiz size bu konuda yardımcı olacaktır.
5
Mümkünse, takson tanıtım yazısı (Taksonomi yazısı) girin.
Bu araç sadece taksonları sisteme girmek için geliştirilmiştir. Dolayısıyla taksonlara ait minimal bilgiye yer vermektedir. Evrim Ağacı olarak amacımız, taksonlara dair detaylı girdilerle bu projeyi zenginleştirmektir. Girdiğiniz türü daha kapsamlı tanıtmak için Taksonomi yazısı girin.
Gönder
Tür Gözlemi Ekle
Tür Seç
Fotoğraf Ekle
Kurallar
Komünite Kuralları
Bu platform, bizzat gözlediğiniz türlerin fotoğraflarını paylaşabilmeniz için geliştirilmiştir. Yapacağınız paylaşımlar Evrim Ağacı'nın kurallarına tabidir. Ayrıca bu komünitenin ek kurallarına da uymanız gerekmektedir.
1
Net ve anlaşılır görseller yükleyin.
Her zaman bir türü kusursuz netlikte fotoğraflamanız mümkün olmayabilir; ancak buraya yüklediğiniz fotoğraflardaki türlerin özellikle de vücut deseni gibi özelliklerinin rahatlıkla ayırt edilecek kadar net olması gerekmektedir.
2
Özgün olun, telif ihlali yapmayın.
Yüklediğiniz fotoğrafların telif hakları size ait olmalıdır. Başkası tarafından çekilen fotoğrafları yükleyemezsiniz. Wikimedia gibi açık kaynak organizasyonlarda yayınlanan telifsiz fotoğrafları yükleyebilirsiniz.
3
Paylaştığınız fotoğrafların telif hakkını isteyemezsiniz.
Yüklediğiniz fotoğraflar tamamen halka açık bir şekilde, sınırsız ve süresiz kullanım izniyle paylaşılacaktır. Bu fotoğraflar nedeniyle Evrim Ağacı’ndan telif veya ödeme talep etmeniz mümkün olmayacaktır. Kendi fotoğraflarınızı başka yerlerde istediğiniz gibi kullanabilirsiniz.
4
Etik kurallarına uyun.
Yüklediğiniz fotoğrafların uygunsuz olmadığından ve başkalarının haklarını ihlâl etmediğinden emin olun.
5
Takson teşhisini doğru yapın.
Yaptığınız gözlemler, spesifik taksonlarla ilişkilendirilmektedir. Takson teşhisini doğru yapmanız beklenmektedir. Taksonu bilemediğinizde, olabildiğince genel bir taksonla ilişkilendirin; örneğin türü bilmiyorsanız cins ile, cinsi bilmiyorsanız aile ile, aileyi bilmiyorsanız takım ile, vs.
Gönder
Tür Ara
Aradığınız türü bulamadıysanız buraya tıklayarak ekleyebilirsiniz.