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 harcıyoruz. için (2*T + 1) saat 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 (( harcadığımız anlamına gelir. 2 geliştirici * X/5 * (2*T + 1)) saat 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 penceresi sırasında birleştirme çakışmalarına sahip yaklaşık %2 PR'nin olduğunu ve PR'lerin her saat başı geldiğini varsayarak, harcayacağız bu çatışmaların çözümünde boşa harcandı. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0,02 * M/8 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 sayıda CI hatasına neden olur . (2*T + 1 saat) * X/5 * M/8 CI'yi çözme zamanı Her derleme hatasında tanıtıcıyı değiştiren yaklaşık on beş dakikalık bağlamla, bu saatlik geliştirici zamanı demektir. (2*T + 1 saat) * X/5 * M/8 * CI hatalarıyla her gün boşa harcanan 0,25 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 saati boşa harcayacaktır. (0,25 * M * F / 100) Verimliliği artırma Bunların çoğu 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 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. . , değişikliklere yönelik Teslimat süresiyle ilişkili DORA metriklerini etkilese de, dağıtım sıklığı, hizmeti geri yükleme süresi DORA ölçümleri hakkında daha fazla bilgi edinin Veya dezavantajları hakkında daha fazla bilgi edinin. 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 gibi hatalı test önleme sistemiyle birleştirerek her hafta yüzlerce mühendislik saatinden tasarruf edebilir. Aviator'ı TestDeck da yayınlandı. Burada
