Efsanevi Adam Ayının etkilerini azaltmanın yolları nelerdir?

Brooks yasası: Geç bir yazılım projesine insan gücü eklemek daha sonra bunu yapar.

No Silver Bullet - Yazılım Mühendisliğinin Özü ve Kazaları adlı kitabında Frederick Brooks, Efsanevi Adam Ayı kavramını şöyle tanımlar :

Brooks'un varsayımı, karmaşık programlama projelerinin , işçiler arasında iletişim olmadan ve görevler ile bunları yerine getiren işçiler arasında bir dizi karmaşık ilişki kurmadan üzerinde çalışılabilen ayrı görevlere mükemmel bir şekilde bölünemeyeceğidir .

1982'den bu yana kesinlikle ilerledik ve bu sorunu hafifletmek için biraz daha deneyim kazandık. Daha fazla sorun yaratmadan bir projeye kaynak eklemek için işinizde başarıyla uyguladığınız çözümlerden bazıları nelerdir.

MMM nedir

Önce Brook Yasası'nın bağlamını açıklamak istiyorum. Onu 1975'te yeniden yaratmasına neden olan varsayım neydi?

Bir Man-ay, bir kişinin bir ay içinde yaptığı işi temsil eden varsayımsal bir çalışma birimidir; Brooks kanunu, yararlı çalışmaları insan aylarında ölçmenin imkansız olduğunu söylüyor.

^{kaynak: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

O zamanlar, karmaşık programlama projeleri büyük monolit sistemler anlamına gelecektir. Ve Brooks, bunların geliştiriciler arasında iletişim olmadan ve görevler ile bunları yerine getiren insanlar arasında bir dizi karmaşık ilişki kurmadan üzerinde çalışılabilecek ayrı görevlere mükemmel bir şekilde bölünemeyeceğini iddia ediyor.

Bu son derece uyumlu yazılım monolitlerinde çok doğrudur. Ne kadar ayrıştırma yapılırsa yapılsın, büyük monolit, yeni programcıların monolit hakkında bilgi edinmesi için gereken zamanı zorunlu kılmaktadır. Ve artan iletişim yükü, mevcut zamanın giderek artan bir miktarını tüketecektir.

Ama gerçekten bu şekilde olmak zorunda mı? Monolit yazmak ve iletişim kanallarını geliştiricilerin sayısına n(n − 1) / 2nerede tutmak zorunda mıyız n?

Binlerce geliştiricinin büyük projeler üzerinde çalıştığı şirketler olduğunu biliyoruz ... ve işe yarıyor. Yani 1975'ten beri değişen bir şey olmalı.

MMM'yi azaltma imkanı

2015 yılında, PuppetLabs ve IT Revolution, 2015 DevOps Durumu Raporu'nun sonuçlarını yayınladı . Bu raporda, yüksek performans gösteren kuruluşlarla yüksek performans göstermeyenler arasındaki farka odaklandılar.

Yüksek performans gösteren kuruluşlar bazı beklenmedik özellikler gösterir. Örneğin, geliştirmede en iyi proje bitiş tarihi performansına sahiptirler. Operasyonlarda en iyi operasyonel kararlılık ve güvenilirlik. Yanı sıra en iyi güvenlik ve uyum sicili.

Raporda vurgulanan şaşırtıcı şeylerden biri, günlük dağıtım sayısı metriğidir. Ancak, yalnızca günlük dağıtımları değil, dağıtım / gün / geliştiriciyi ve yüksek performans gösteren kuruluşlara yüksek performans göstermeyenlere kıyasla daha fazla geliştirici eklemenin etkilerini de ölçtüler.

Bu rapordaki grafik -

Düşük performans gösteren organizasyonlar Efsanevi Adam Ay varsayımlarına uyar. Yüksek performanslı kuruluşlar konuşlandırma / gün / dev sayısını geliştiricilerin sayısına göre doğrusal olarak ölçeklendirebilir.

Gene Kim'in DevOpsDays London 2016'da mükemmel bir sunumu bu bulguları anlatıyor.

Nasıl yapılır

İlk olarak, yüksek performanslı bir organizasyon nasıl olunur? Bunun hakkında konuşan birkaç kitap var, bu cevapta yeterli alan yok, bu yüzden sadece onlara bağlanacağım.

• İyi ila Harika: Neden Bazı Şirketler Sıçradı? Ve Diğerleri Jim Collins Tarafından Yapılmıyor
• Yüksek Hız avantajı: Pazar Liderleri Rekabetin Üstesinden Gelmek İçin Operasyonel Mükemmelliği Nasıl Kullanıyor? Steven Spear
• Sanayi, Hükümet, Eğitim İçin Yeni Ekonomi W. Edwards Deming

Yazılım ve BT kuruluşları için, yüksek performanslı bir kuruluş olmanın kritik faktörlerinden biri: kalite ve hıza odaklanma .

Örneğin Ward Cunningham Teknik Borçları açıklanmasına izin verdiğimiz her şey olarak açıklıyor . Bu, yönetim tarafından kabul edilir, çünkü her zaman zaman olduğunda düzeltileceğini vaat eder.

Asla yeterli zaman yoktur ve teknik borçlar gittikçe kötüleşir.

Teknik borcun artmasına neden olan bu şeyler nelerdir?

• eski kod
• ortamların manuel yapılandırması
• manuel test
• manuel dağıtımlar

Eski kod Michael Feathers tarafından Eski Kod ile Etkili Çalışma bölümünde tanımlandığı gibi , otomatik teste sahip olmayan herhangi bir koddur.

Kodu üretime almak için her zaman kısayolu kullanılır; operasyonlar bu borcun sonsuza dek sürdürülmesi ile yükümlüdür. Ardından dağıtım süreci uzar.

Gene sunumunda altı hafta süren dağıtımları olan bir şirket hakkında bir hikaye anlatıyor. On binlerce son derece hataya meyilli sıkıcı adım içeren, 400 kişi bağladı ve bunu her yıl dört kez yapacaklardı.

DevOps'un ilkelerinden biri, güvenilirliğin daha küçük dağıtımları daha sık yapmaktan kaynaklanmasıdır.

Misal

• Jon Jenkins Velocity 2011'de : Amazon günde 15 bin dağıtım yapıyor
• Ken Exner AWS Zirvesi 2015'te : Amazon / gün 136 bin dağıtım yapıyor

Bu iki sunum, Amazon'un kodu üretime dağıtma süresini azaltmak için yaptığı tüm şeyleri gösterir.

Gene'ye göre, bu yüksek performanslı organizasyonlarda zaman içinde değişen tek şey geliştiricilerin sayısıdır. Amazon örneğinden, dört yıl içinde sadece daha fazla insan ekleyerek dağıtımlarını on kat artırdıklarını söyleyebilirsiniz.

Belirli koşullar altında, sağ mimarisi ile sağ teknik uygulamalar, sağ kültürel normlar, geliştirici verimliliği Bu araçlar olabilir geliştiricilerin sayısı olarak ölçek artar. Ve DevOps kesinlikle tüm bunların ortasında.

Yaptığım (ve bu sadece öznel) aşağıdaki gibidir:

Son tarihi düşünen bir yönetici, gerekli zamanı kısaltmak için insanları ekibime eklemek istediğinde ve MMM altında göründüğünde, öncelikle onunla bunun neden kötü olabileceğini tartışıyorum. Bunun en sevdiğim benzetmesi, bir kadının dokuz ayda bebek sahibi olabilmesi durumunda dokuz kadının bir ayda bir bebeği olmayacağını, ancak dokuz ayda dokuz bebeğinin olacağını hatırlatmaktır. Zaman kesilmez, sadece paralel işleme daha iyidir.

Karar ekibimize zorlandığında, genellikle bazı görevleri daha fazla bölmeye çalışırız ve bu mümkün olmadığında, genellikle bir programcının yazmaktan sorumlu olduğu ve diğerinin kodu diktiği (ve periyodik olarak değiştirdiği) çift ​​programlamaya güveniriz. ).

Kod yazmanın kendisi daha yavaştır, ancak yazarken yapılan kaçınılmaz inceleme nedeniyle test sırasında daha az yazım hatası / linting ve hata var. Genel kod kalitesi de biraz daha iyi hissediyorum, ama bu iddiayı destekleyecek hiçbir ölçüt yok.

Sadece bir CI perspektifinden bahsetmişken, bir proje üzerinde çalışan geliştiricilerin sayısını artırmak genellikle aynı dalda çalışan daha fazla insana dönüşür.

Geleneksel CI sistemleri bu açıdan bir ölçeklenebilirlik sorununa sahiptir: kırılma / gerileme / tıkanma olasılığı entegrasyon hızını yavaşlatır ve daha küçük takımları kırıp çocuk dallarına geçmeye davet eder (yani daha fazla yavaşlama). Bkz . Çok büyük projeler / ekipler için sürekli entegrasyon nasıl ölçeklenebilir? . Bu, Efsanevi Adam Ay konsepti boyunca oynuyor.

Bu soruya cevabımda önerdiğim çözüm, yüksek düzeyde ölçeklenebilir bir CI sistemi, tüm büyük ekipler için (büyük boyutlarda bile) gerçek CI - tek şube / gövde tabanlı entegrasyona geçişi sağlayacaktır.

Aynı sayfanın herkesiyle, aynı otomatik araçları / süreçleri ve CI sisteminin kendi içinde otomatik hale getirilen KG doğrulamalarının büyük çoğunluğunu kullanarak rolleri değiştirmek ve ekip üyeleri arasında odaklanmak çok daha kolay hale gelir. Tüm gelişim süreçleri daha pürüzsüz, daha öngörülebilir, daha rahat hale gelir.

Yeni insanları böyle bir ortama taşımak, daha deneyimli ekip üyelerinden daha az zor görevleri yükleyerek onları daha zor görevler üstlenerek üretken hale getirmek böylece daha kolay olur.

Tüm bunların, Efsanevi Adam Ayı kavramının etkilerini yatıştırıcı olarak gördüğüne inanıyorum.