Ar-Ge KPI'sı nasıl tanımlanır: ekip hızına dayalı
Bir buçuk yıl önce Bizzabo'daki Ar-Ge ekibine liderlik ediyordum.
Sorumlu kişi olduğumdan beri, ekibin sağladığı gerçek değeri yansıtmak için Ar-Ge ekibinin performansını ölçmenin en iyi yolunu arıyordum. Ekip performansını izlemek için başlangıçta endüstri standardı ölçümleri kullandık: planları ve teslimatı ölçme.
Ekibimizin KPI'ları aşağıdadır:
- % 20'ye kadar sapma : Daha iyi planlama için
- Görev başına ortalama iki gün : Küçük görevlerin daha iyi ele alındığına ve daha iyi yürütüldüğüne inanıyoruz;
- Sistem çalışma süresi% 99,95
Karşılaştığım zorluk, bu temel performans göstergelerinin Ar-Ge ekibinin gerçek değeriyle doğrudan ilişkili olmamasıdır. Hız yavaş ve kalite düşük olsa bile bu KPI'leri kolayca uygulayabiliriz.
6 aylık yineleme ve değişiklikten sonra, iyi işleyen bir Ar-Ge ekibinin değerini - ekibin hızı ve kalitesini daha iyi yansıtmak için Ar-Ge KPI'larını tanımlamaya karar verdim.
Duraklamak ve CodeClimate ekibinin ürünü olan Velocity hakkında bilgi edinmek istiyorum. Bugün olduğumuz yere gelmemize yardımcı oldu.
"Gelişme hızı" teriminin neleri kapsadığını gözden geçirelim.
çalışma alışkanlığı
- Haftalık kodlama günü sayısı
- Günlük kod itme sayısı (mümkün olan en kısa sürede, az miktarda itme)
- Çekme talebi (PR) boyutu
- İnceleme talebinden birleşmeye kadar geçen süre
Kod kalitesi
- Kod karmaşıklığı
- Kod belgeleri
- Test kapsamı
- Böcek sayısı
- Sistem çalışma süresi
etkililik
- Yeniden işleme oranı
- PR Vazgeçme
- Geri alma sayısı
En hızlı yatırım getirisini elde edebilecek KPI'ları seçmek ve önceliklendirmek için her bir maddeyi derinlemesine öğrendik.
Haftalık kodlama günü sayısı
Bir ekip üyesinin haftalık olarak kodladığı ortalama gün sayısı (en az bir gönderilen push olarak tanımlanır). Bir gönderimin durumu iyi yansıtmadığını düşünebilirsiniz, ancak basit bir taneyle başlamanızı veya ölçülmesi kolay daha iyi bir dizin bulmanızı öneririm.
Haftalık kodlama günü sayısı
Günlük kod itme sayısı
Birim zamanda aktif katılımcı başına kaç çekme isteği (PR) birleştirilir.
Günlük kod itme sayısı
PR boyutu
Bizim için PR ne kadar uygun, bu biraz daha derinlemesine anlamamızı gerektiriyor. Ancak nasıl net bir değer belirleyeceğimizden emin değiliz. İşin püf noktası bir kod satırı bulmak. Meslektaşlarım kod incelemesini ve PR onayını bir saatten daha kısa sürede tamamlayabilirler.
Bir saatten uzun süren kod incelemesi zorlu bir görev olabilir, bu nedenle inceleme eksik olabilir. Buna karşılık, üretim ortamına daha fazla hata girdikçe, 33 saat tasarruf etmek zor olacaktır. Optimum PR boyutu 250 satırdan az koddur. Aslında, PR'larımızın çoğu daha küçüktür.
PR boyut dağılımı
İnceleme talebinden birleşmeye kadar geçen süre
PR'nin üretim ortamına bir huni olarak yayınlanması için geçmesi gereken her adımı düşünün: inceleme süresi > İşlem süresi > Zamanı birleştirin.
Açık bir dahili SLA'ya sahip olmak istiyoruz, böylece PR'lerin% 80'i bu huniyi bilinen bir süre içinde geçecek. Bu bir dengedir ve her ekibin zihniyeti ve kültürü farklı olabilir. Bir yandan, geliştiricilerin inceleme için çok uzun süre beklemesini istemiyoruz. Öte yandan, gözden geçirenlerin bağlam değiştirme için mevcut görevi askıya almaya zorlanmasını önlemek istiyoruz. hedefimiz:
- İnceleme süresi: 12 saat (aynı gün inceleme)
- Onay süresi: ilk incelemeden 3 saat sonra
- Birleştirme süresi: Onaydan 12 saat sonra
Ayrıca mutfakta çok fazla şef olmasını önlemek için en fazla 2 hakem olması gerektiğini şart koşuyoruz.
Kod karmaşıklığı
Tanım Denetim yapılarında en az 4 seviye yuvalama derinliğine sahip uygulama kodu satırlarının sayısı (if ifadeleri, döngüler vb. Gibi).
KPI bin kod satırı başına karmaşık kod sayısı.
Aşağıdaki resimden, yıllar içinde kod tabanını nasıl basitleştirdiğimizi görebilirsiniz. Bu, büyük ölçüde yeni teknolojileri (React / Redux, Kotlin, mikro hizmetler, Dockers ve K8'ler) benimseyerek ve kod kültürümüzü geliştirerek elde edilir.
Zaman içinde kod karmaşıklığındaki değişiklikler
Kod belgeleri
"Belgeleme yok" konseptine bağlıyız. Herkesin kolayca anlayabileceği basit bir kod yazmamız gerektiğine inanıyoruz (ancak adil olmak gerekirse, bazı yorumlarımız var).
Test kapsamı
Ar-Ge ekibimizin özel bir kalite güvence ekibi yoktur. Her geliştirici kendi testlerini (birim testleri ve uçtan-uca testler) yazar ve sürüm kalitesinden Squad sorumludur. Kapsanmayan yeni kod yayınlanmayacaktır. Her derlemede tam otomatik testler çalıştırılır.
Böcek sayısı
Hataların ölçülmesi zordur. Onları ne zaman takip ediyorsunuz? Hata nedir? Mükemmel müşteri destek ekibimiz çok iyi bir iş çıkarır (ilk yanıt süresi 1,5 saatten azdır) ve ilgili sorunları yalnızca Ar-Ge yükseltme ekibimize iletir (bir ekip lideri boşluğumuz var). Hataların sayısını ve ciddiyetini her ay ölçüyoruz. Ama takım büyüdükçe ne yapacaksın? Hepimiz biliyoruz ki ne kadar çok kod yazarsanız, o kadar çok hata olur.
Belirli bir aydaki kod satırı sayısı ile hata arasındaki ilişkiyi, yayın sayısı (tam bir CI / CD'ye sahibiz) ve hata arasındaki ilişkiyi bulmak için derinlemesine bir analiz yapacağız.
Son olarak, toplam birleşik PR sayısının böcek sayısına oranını ölçmeye karar verdik.
Önem düzeyine göre müşteriler tarafından bildirilen hataların sayısı
Zaman içinde toplam birleşik PR'deki değişim
KPI'yı 0,2 olarak tanımlıyoruz (birleştirilmiş 5 PR başına bir hata), acil hata yok
Sistem çalışma süresi
Bu çok basit. Amacımız, müşterilerimizin en yüksek kalitede hizmet kullanılabilirliğini almalarını sağlamak için aylık çalışma süremizi ölçmektir. Bunun için statuscake kullanıyoruz.
Yeniden işleme oranı
Yeniden düzenlenmiş kod satırları, aynı yazar tarafından 3 hafta içinde gönderilen ve düzenlenen tüm kod satırlarıdır. Yeniden işleme oranı, aşağıdaki formül kullanılarak hesaplanır: (farklı yeniden işleme için toplam satır sayısı) / (farklı modifikasyonlar veya eklemeler için toplam satır sayısı).
Yeniden çalışmayı ölçmenin doğru veya yanlış bir yolu yoktur, çünkü bu daha çok takıma veya şirkete özgü bir göstergedir. Bu, özellikle bazı ekiplerin içeriden dışarıya daha yüksek bir yeniden çalışma oranına sahip olduğunda veya bazı ekipler dikkatli bir planlamadan sonra, bazen hızlı ürün yinelemelerinde çalışmaya başladığında geçerlidir.
Ana fikir, her bir özelliğin gelişimini gözden geçirmek ve yeniden çalışmanın gereksinimlerdeki değişikliklerden mi yoksa yeterli teknik rehberlik eksikliğinden mi kaynaklandığını görmektir.
PR Vazgeçme
Bir çekme isteği birleştirilmeden açılır ve kapatılırsa, "terk edilmiş" olarak kabul edilir. Ayrıca 3 günden uzun süredir etkin olmayan çekme isteklerini de dahil ettik. Bu, bağlam değiştirmeyi en aza indirirken en önemli görevlere odaklanmamızı ve işimizin boşa gitmemesini sağlar.
Yaşa göre terk edilmiş PR'lara baktığımızda, 30 günden eski PR'lerin% 90'ının bir daha asla birleştirilemeyeceği, yani kayıp kod olduğu aşikardır. Boru hattını temizledikten ve asla birleştirilmesi amaçlanmayan PR'leri çıkardıktan sonra (POC, test ve diğer bazı dahili gereksinimler gibi), eski PR'leri gözden geçirecek ve nedenlerini anlayacağız. Bunun ürün önceliğinde bir değişiklik olup olmadığını belirleyebiliriz veya yanlış bir tahmin vb. Nedeniyle bir planı asla sonlandırmadık.
Gördüğünüz gibi, bu KPI'ye odaklanmak ve iyi bir süreç geliştirmek, ekip çalışma alışkanlıklarımızı daha tutarlı hale getirdi; ekipler arasındaki sapma azaldı (Temmuz ayından bu yana yeni bir KPI süreci başlattık).
Her Squad tarafından düşürülen PR
Geri alma sayısı
Birleştirmeden sonra kaç tane kod yedeği var? Geri dönüşler genellikle anlık hataların (kalite) veya eksik ürün / özelliğin hızlı anlaşılmasının sonucudur. Hedefimiz belirli bir değer değildir, ancak her geri dönüşü özel bir inceleme için tetikleyici olarak kullanırız.
Öyleyse, KPI olarak ne kullanıyoruz?
1. İyi bir Ar-Ge KPI'sının özelliklerini tanımladık:
- Bireylerden Squad'a (Spotify modelini kullandık) tüm takıma ölçülebilir;
- Verimlilik artışını yansıtın ve teşvik edin;
- İşin kalitesiyle ilgili (kod);
- Daha iyi hale getirmek için takıma meydan okuyun;
- En kaliteli ürünleri en kısa sürede teslim edin.
2. Yukarıdaki tüm analizleri yaptıktan sonra, aşağıdaki takım KPI'larını kullanmaya karar verdik:
- Aktarım hızı: Katkıda bulunan başına ayda 15 PR birleştirilir; (Birim zamanda aktif katılımcı başına birleştirilen PR sayısı)
- Verimlilik: PR terk oranı% 5'ten az; (Bir çekme isteği birleştirilmeden açılır ve kapatılırsa, "terk edilmiş" olarak kabul edilir. 3 günden uzun süredir etkin olmayan PR'leri de dahil ederiz.)
- Kalite: çalışma süresi% 99.98;
- Kalite: Her bir birleşik PR, ortalama 0,2 hataya sahiptir ve acil iş emri yoktur.
Orijinal İngilizce metni görüntüleyin: RD planlama VS yürütme ölçümünü durdurun. Takım hızını ölçmeye başlayın
