Belirli programlama dilleri, araçları ve teknolojileri hakkında pratik beceriler ve bilgi, bir yazılım geliştirici olarak tam zamanlı bir işe girmenin anahtarı olsa da, birçok yönden bu meslekte başarı için bir ön koşul olarak görülebilecek başka bir değerli gösterge daha vardır: verimlilik. Verimlilik ölçümü, tüm profesyonel yazılım geliştiricilerin anlaması ve hesaba katması gereken bir şeydir, çünkü performans ölçümleri günümüzün iş ortamındaki herhangi bir yazılım geliştirme ekibi için doğası gereği önemlidir.
Bir geliştirici olarak üretkenliğiniz neden önemlidir?
Çevik geliştirme, DevOps ve küçülen yazılım sürüm döngüleri çağında, geliştiricilerin ürünlerin yeni sürümlerini mümkün olan en kısa sürede göndermeleri gerektiğinde, şirketler bireysel programcıların ve bir ekibin performansını bir bütün olarak değerlendirmek için çok sayıda farklı üretkenlik ölçümü kullanır. Buna bir geliştiricinin bakış açısından bakıldığında, performans ölçümü, programlama becerilerinizdeki ilerlemeyi izlemenize yardımcı olarak, tutarlı profesyonel gelişim elde etmenizi sağlayacak bir dizi değerli amaca hizmet edebilir. Son derece üretken kodlayıcılar, sonunda dudak uçuklatan maaş teklifleri alan ve en heyecan verici projelerde çalışmaya başlayan kişilerdir. Ancak, tam olarak başarılı biri olmasanız ve yalnızca yazılım geliştirmede herhangi bir iş isteseniz ve bu işte makul derecede başarılı olsanız bile, yine de en azından performans göstergeleri ve işteki girdilerinizin üretkenliğini ölçmek için nasıl kullanıldıkları hakkında temel bir anlayışa sahip olmanız gerekir. Bugün hakkında konuşacağımız şey bu.
Yazılım geliştirme üretkenliği ölçüm metrikleri
Yazılım geliştirme üretkenlik ölçütleri nelerdir?
Yazılım geliştirme ölçütleri, bir geliştiricinin performansını, iş kalitesini ve üretkenliğini izlemek için nicel ölçümlerin uygulanabileceği programlama işi alanlarıdır. Her üretkenlik ölçümü, geliştirme sürecinden veri almaya ve bunu üretkenliği ölçmek için kullanmaya dayanır. Yazılım geliştirmeyle ilgili hemen hemen hiçbir şey kolay ve anlaşılır olmadığından, programlama üretkenliğini ölçmenin de oldukça tutarsız ve sektör genelinde parçalanmış olduğunu söyleyebilirsiniz. Ya da basitçe söylemek gerekirse, çeşitli ekipler ve şirketler tamamen farklı performans göstergeleri kullanabilir ve bu konuya birkaç açıdan yaklaşabilir. Böylece, yazılım geliştirme ekipleri tarafından kullanılabilecek her bir ölçümü öğrenmekle uğraşmanıza gerek kalmaz.
Ne tür yazılım geliştirme üretkenlik ölçütleri vardır?
Doğal olarak, performansı ölçmeye çeşitli düzeylerde ve açılardan yaklaşan çok sayıda farklı üretkenlik ölçüsü vardır. Bu tür üretkenlik ölçümlerinin en yaygın türleri şunlardır:
Resmi boyut odaklı metrikler.
Bu ölçümler, bir programcının kod satırları (LOC), kod talimatları uzunluğu, kod karmaşıklığı vb.
Zaman ve işlev odaklı üretkenlik ölçümleri.
Şelale yazılım geliştirmede kullanılan aktif günler, belirli bir zaman diliminde sevk edilen işlevsellik kapsamı, kod kayıp oranları, atanan görev sayısı vb. gibi çeşitli geleneksel üretkenlik ölçütleri vardır.
Çevik geliştirme süreci ölçümleri.
Sprint tükenmişlik raporu, hız, teslim süresi, döngü süresi ve diğerleri gibi çevik geliştirme süreci ölçütleri, günümüzde yazılım geliştirme ekipleri arasında muhtemelen en yaygın kullanılan ölçütlerdir. Çevik metriklerden yazının ilerleyen kısımlarında daha detaylı olarak bahsedeceğiz.
Operasyonel analitik ölçümleri.
Bu ölçüm seti, yazılımın mevcut üretim ortamındaki performansını ölçmeye odaklanır. Arızalar arasındaki ortalama süre (MTBF), ortalama kurtarma süresi (MTTR) ve uygulama kilitlenme oranı burada en çok kullanılan ölçümlerdir.
Test metrikleri.
Yazılım testi, sistem testinin kalitesini ölçmek için otomatik testlerin yüzdesi, kod kapsamı vb. gibi kendi ölçüm setine sahiptir.
Müşteri memnuniyeti ölçütleri.
Son olarak, herhangi bir yazılım parçası için nihai ölçüm son müşteri deneyimidir ve bunun için de müşteri çaba puanı (CES), müşteri memnuniyeti puanı (CSAT), net tavsiye puanı (NPS) gibi bir dizi ölçüt vardır. ve diğerleri.
Çevik yazılım geliştirme ölçümleri
Gördüğünüz gibi, yazılım üretkenliği ölçütlerinin tüm inceliklerinde kaybolmak oldukça kolaydır. Bununla birlikte, normal bir yazılım geliştiricisinin aşina olması gereken tek şey, bugün yazılım geliştirme ekipleri tarafından yazılım geliştirme yaşam döngüsünün farklı bölümlerinde ekip üretkenliği ölçüm standartları olarak yaygın olarak kullanılan Çevik ölçütlerdir. Ana ve en sık kullanılan Çevik metrikleri listeleyelim.
1. Sprint Burndown.
Sprint Burndown raporları, çevik scrum geliştirme ekipleri için temel ölçütlerden biridir. Çevikte olduğu gibi, geliştirme süreci zamana bağlı sprintler aracılığıyla düzenlenir, Sprint Burndown, bir sprint sırasında görevlerin tamamlandığını izlemenin bir yolu olarak kullanılır. Bir ölçü birimi olarak saat veya hikaye puanları kullanılır. Amaç, tutarlı bir ilerleme sağlamak ve ilk projeksiyonlar doğrultusunda iş teslim etmektir. Sprint Burndown, ekiplerin çalışma temposunu ölçmelerine ve gerektiğinde ayarlamalarına yardımcı olur.
2. Takım Hızı.
Hız, yine bir ölçü birimi olarak saatlere veya hikaye noktalarına dayalı olan bir diğer önemli göstergedir. Bir takımın bir sprint sırasında tamamladığı ortalama iş miktarını ölçer ve tüm proje boyunca tahmin ve planlama için kullanılır. Takip hızı, ekibin tutarlı performans sağladığından emin olmak için önemlidir.
3. Hikaye Puanları.
Bir programcının her yayın sırasında sunduğu öykülerin boyutu, bu kodlayıcının üretkenliğinin bir göstergesi olduğundan, bireysel bir geliştirme ekibi üyesi düzeyinde, öykü puanları değerli bir ölçümdür.
4. Döngü Kontrol Tablosu.
Bir görev veya başka bir biriktirme listesi öğesi üzerindeki çalışmanın başladığı andan tamamlanmasına kadar geçen toplam süreyi ölçer. Daha öngörülebilir sonuçlar sağlayan döngü sürelerini izlemeyi ve kontrol etmeyi sağlar.
5. Verim ve Sağlanan Değer.
Proje yöneticileri, geliştiricilere atanan görevleri analiz eder ve onlara değer atar. Bu metrik daha sonra ekibin verimini veya başka bir deyişle yapılan katma değerli iş miktarını ölçmek için kullanılır.
6. Kod Karışıklığı.
Kod karmaşası, hem bir takımın üretkenliğini ölçmek hem de bireysel programcıların performansını izlemek için kullanıldığı için bahsetmeye değer başka bir ölçümdür. Kod karmaşası, bir geliştiricinin önceden eklenmiş kod satırlarını ne sıklıkta kaldırdığını veya bu satırlarda değişiklik yaptığını ve önceden yazılan kodun yüzde kaçının değiştirildiğini veya atıldığını ölçer.
Uzman görüşleri
Son olarak, biraz perspektif katmak için, konuyla ilgili deneyimli yazılım geliştirme endüstrisi profesyonellerinden birkaç alıntı. "Umarım ölçümlerinizi bir tür standartla veya hatta başka bir şirketteki başka bir ekibin performansıyla "karşılaştırmaya" çalışmıyorsunuzdur. Çalıştığım her yerde, hikaye noktaları, hız, saatlik tahminler, görevler vb. tanımlarında benzersiz farklılıklar vardı; eski Teknik Ürün Müdürü ve Çevik Koç Cliff Gilley şunları söyledi :. "Takım performansını yönlendirmek söz konusu olduğunda ölçütler konusunda biraz temkinliyim. Yalnızca bir veya iki değişkene dikkat ettiğinizde, (kasıtlı olarak veya başka bir şekilde) metriği oynamaya düşmek ve kendinizi iyileştirdiğiniz konusunda kandırmak çok kolay hale gelir - yaptığınız tek şey metriği iyileştirmekken. Örneğin, hıza dayalı metrikler, ekibin daha küçük katlara geçmesiyle "gelişebilir" (kat başına daha az iş - yani daha fazla kat tamamlanır - böylece hız artar). Hikayeler, iş değerinde daha küçük artışlar sağlayan kullanışlı kullanıcı hikayeleriyse, bu iyi bir şey olabilir. Başka bir endüstri profesyoneli olan Adrian Howard, "Öykülerin daha küçük ve daha "teknik" görevler haline gelmesi ve kendi başlarına gerçek değer sağlamayan olması kötü bir şey olabilir" dedi .. "Çekmeye dayalı bir sistemde çalışırken, iş hacmine ve döngü süresine değer veriyorum. İlki bana ekibimizin kapasitesi hakkında genel bilgi veriyor ve zamanla çok güçlü bir tahmin ölçüsü haline gelebilir. İkincisi, boru hatlarımızın verimliliğinin genel bir ölçüsü olarak yararlıdır. Döngü süresi yüksekse, boru hattına bakmaya başlamanın zamanı gelmiştir, çünkü muhtemelen hafifletmek/sömürmek için çalışabileceğimiz bir kısıtlama vardır. Ancak metrikler sadece araçlardır. Bunların arasında kaybolmayın ve kesinlikle belirli bir ölçüme yönelik planlama yapmaya başlamayın. Ekip olarak ne yaptığınızı ve doğal olarak nasıl çalıştığınızı düşünün, ardından sistemi insanlar etrafında kurun. Metrikler, sisteminizin herkesin çalışmasını nasıl desteklediğini görmenize yardımcı olacaktır. Ya da değil, ” diye bitirdi video oyunu geliştirme yapımcısı Dave Cerra .
GO TO FULL VERSION