Aviator'dan Yenilik: Mühendislik Verimliliğini Değerlendiren Hesap Makinesi

Mühendislik üretkenliğini ölçmek karmaşık bir süreçtir; geliştiricilerin zamanlarını nasıl harcadığına dair tam bir resim elde etmek zordur. Verimliliği ölçmenin yaygın bir yolu, DORA veya SPACE gibi sistem ölçümlerini analiz etmektir. Bunlar, endüstri standartlarıyla karşılaştırıldığında ekibin verimliliğini anlamak için son derece yararlı ölçümler olabilir. Bu ölçümlerin her birini derinlemesine incelemek, ekibi neyin yavaşlattığına dair bilgiler de sağlayabilir.

Ancak bazen geliştiricilerin gün boyunca harcadığı ve üretkenliği etkilediği algılanmayan "gizli cepler" de vardır. Ancak bunları toplamaya başladığımızda rakamlar endişe verici olabiliyor.

Örneğin, bir geliştiricinin, hatalı bir testte hata ayıklamak ve testin kendi değişikliklerinden dolayı başarısız olup olmadığını anlamaya çalışırken harcadığı zamanı düşünün. Veya ana hat oluşturma hatasını çözmeye çalışan bir geliştiricinin harcadığı zaman.

Bu perspektifi sağlamak için mühendislik verimliliğini değerlendirmede yardımcı olan bir hesap makinesi geliştirdik. Bu hiçbir şekilde mühendislik ekibinizin verimliliğine ilişkin tam bir analiz sağlamaz. Sağladığı şey, genellikle daha yaygın verimlilik ölçümlerinde görünmeyen, boşa harcanan zamanın "gizli ceplerine" bir bakıştır.

Hesaplayıcı, geliştirici iş akışlarındaki derleme ve test hataları nedeniyle sizin ve ekibinizin ne kadar zaman kaybettiğine odaklanır.

Bunu DORA metrikleriyle karşılaştırırsanız değişikliklerin teslim süresinin derleme ve test kararsızlığından önemli ölçüde etkilendiğini görürsünüz. Bu etki bu hesaplayıcı kullanılarak değerlendirilebilir.

Nasıl çalışır

GitHub etkinliklerinize ve GitHub şubelerini nasıl kullandığınıza göre veri girmenizi rica ediyoruz. Aşağıdaki gerçek hesaplamaları açıklamak için her birine değişken atayalım:

M – PR'ler günlük olarak birleştirildi

X – bir hafta içinde ana hat arızaları

T – ortalama CI süresi

F – pullanma faktörü %

Bu girdilere dayanarak, mühendislik ekibinizin derleme hatalarını yönetmek ve hatalı testlerle uğraşmak için haftalık olarak ne kadar zaman harcadığını tahmin ediyoruz. Sonuçları tek tek inceleyelim.

Düzeltmek için harcanan saatler

Bu, bir ana hat derleme hatası tespit edildiğinde tanımlamak, önceliklendirmek, düzeltmek ve derlemenin tekrar geçmesini sağlamak için kaç saatin boşa harcandığını hesaplar. Genellikle büyük bir ekipte birisi bozuk ana hat yapısını fark edecek ve rapor edecektir.

Bir ana hat derleme hatasının, hata ayıklama ve düzeltme için ortalama 1-3 geliştiricinin görev aldığını varsayıyoruz. Sorunun bildirilmesi ve düzeltmenin iletilmesi için gereken sürenin ortalama bir saat olduğunu düşünürsek, sorunu takip etmek, araştırmak ve çözmek için (2*T + 1) saat harcıyoruz.

Bu, haftada X arıza olması durumunda, her gün ana hat derleme arızalarıyla mücadele etmek için geliştirici süresinde (( 2 geliştirici * X/5 * (2*T + 1)) saat harcadığımız anlamına gelir.

Birleştirme anlaşmazlıklarını çözmek için harcanan saatler

Geri almalar ve birleştirme çakışmaları başka sorunlara neden olabilir. Bozuk derleme süresi ((2*T + 1) * X/5) penceresi sırasında birleştirme çakışmalarına sahip yaklaşık %2 PR'nin olduğunu ve M/8 PR'lerin her saat başı geldiğini varsayarak, harcayacağız ((2* T + 1) * X/5) * 0,02 * M/8 bu çatışmaların çözümünde boşa harcandı.

Bozuk yapılardan dolayı haftalık CI hataları

Ekip, özellik dallarını temel almak için altın bir dal kullanmıyorsa, muhtemelen arızalı bir ana hat dalının üzerinde özellik dalları oluşturacaktır. Herhangi bir zamanda oluşturulan PR sayısı, ana hat dışındaki ortalama özellik dalları sayısına benzer olacağından, bu, her gün meydana gelen (2*T + 1 saat) * X/5 * M/8 sayıda CI hatasına neden olur .

CI'yi çözme zamanı

Her derleme hatasında tanıtıcıyı değiştiren yaklaşık on beş dakikalık bağlamla, bu (2*T + 1 saat) * X/5 * M/8 * CI hatalarıyla her gün boşa harcanan 0,25 saatlik geliştirici zamanı demektir.

Kesintili testleri yeniden çalıştırmak için harcanan zaman.

Benzer şekilde, kesikli testlerde, testin kesikli mi yoksa gerçek mi olduğunu araştırmak için gereken bağlam değiştirme süresi ve testlerin yeniden çalıştırılması çalıştırma başına ortalama on beş dakika sürer. Kesinti faktörüne bağlı olarak geliştiriciler her gün (0,25 * M * F / 100) saati boşa harcayacaktır.

Verimliliği artırma

Bunların çoğu , değişikliklere yönelik Teslimat süresiyle ilişkili DORA metriklerini etkilese de, mühendislik ekibi iş akışlarındaki verimsizlikleri ölçme açısından henüz sadece yüzeydeyiz. Derleme ve test hatalarının etkisi aynı zamanda dağıtım sıklığı, hizmeti geri yükleme süresi ve sistemdeki hatalı testlerin kalıcılığı gibi diğer DORA ölçümlerini etkileyen gecikmeli sürümlere de yol açar ve bu da daha yüksek Başarısızlık şansına yol açabilir. DORA ölçümleri hakkında daha fazla bilgi edinin . Veya dezavantajları hakkında daha fazla bilgi edinin.

Aviator'ı büyük mühendislik ekiplerinin karşılaştığı bu gizli zorlukların bazılarını çözmek için geliştirdik. Günümüzde pek çok mühendislik kuruluşu Aviator MergeQueue'yu kullanarak yapıları bozmadan birleştirme iş akışlarını ölçeklendirebiliyor. Ekipler, bunu TestDeck gibi hatalı test önleme sistemiyle birleştirerek her hafta yüzlerce mühendislik saatinden tasarruf edebilir.

Burada da yayınlandı.