Hız (yazılım geliştirme) - Velocity (software development)
 | Bu makale için ek alıntılara ihtiyaç var doğrulama. (Mayıs 2018) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin) |
| Yazılım geliştirme |
|---|
| Çekirdek aktiviteleri |
| Paradigmalar ve modeller |
| Metodolojiler ve çerçeveler |
| Destekleyen disiplinler |
| Uygulamalar |
| Araçlar |
| Standartlar ve Bilgi Yapıları |
| Sözlükler |
| Anahatlar |
Hız yapılan iş için bir metriktir ve genellikle Çevik Yazılım Geliştirme.[1]
Hız ölçümü bazen denir hız takibi.[kaynak belirtilmeli ] Hız metriği, sprintleri planlamak ve takım performansını ölçmek için kullanılır. Hızın ölçülmesinin planlama etkinliğini veya ekip performansını iyileştirdiğine dair hiçbir bilimsel kanıt yoktur. Dahası, metrik yanıltıcı olabilir.[kime göre? ]
Terminoloji
Hız izlemede aşağıdaki terminoloji kullanılır.
- İş birimi
- Ekip tarafından hızı ölçmek için seçilen birim. Bu gibi gerçek bir birim olabilir mühendis saatleri, mühendis günleri veya Ürün İş Listesi Öğeler (PBI) veya hikaye noktaları.[2] Yazılım geliştirme sürecindeki her görev daha sonra seçilen birim açısından değerlendirilmelidir.
- Aralık
- Aralık, hızın ölçüldüğü yazılım geliştirme sürecindeki her yinelemenin süresidir. Aralığın uzunluğu ekip tarafından belirlenir. Çoğu zaman, aralık bir haftadır, ancak bir ay kadar uzun da olabilir.
Prensip
Hızın arkasındaki ana fikir, ekiplerin belirli bir süre içinde ne kadar işi tamamlayabileceklerini önceden benzer işlerin ne kadar hızlı tamamlandığına bağlı olarak tahmin etmelerine yardımcı olmaktır.[3] Hız göreceli ölçüdür. Başka bir deyişle, ham sayılar çok az şey ifade ediyor; önemli olan trend.[4]
Eleştiri
Hızla ilgili bir sorun, yapılan işi planlama doğruluğu ile birleştirmesidir. Başka bir deyişle, bir ekip görevleri daha ihtiyatlı bir şekilde tahmin ederek hızı artırabilir. Bir takım bir görevin iki saat sürmek veya iki puan değerinde olmak yerine dört saat süreceğini veya 4 puan değerinde olduğunu söylerse, hızları daha iyi görünecektir (bazen nokta şişirme olarak adlandırılır).[5] Hız, bir performans ölçütü olarak kullanılmamalıdır.[1]
Hızla ilgili ikinci bir sorun, kaliteyi, kullanıcı hedefleriyle uyumu veya önceliği hesaba katmamasıdır. İyi tasarım, yeniden düzenleme, kodlama standartları ve teknik borç ihmal edilerek hız artırılabilir. Özelliklerin olabildiğince çabuk tamamlanması, kaliteden bağımsız olarak hızı artırır. Benzer şekilde, hız, o işin faydalarından bağımsız olarak yapılan işi içerir. Örneğin, hiç kimsenin istemediği veya ihtiyaç duyduğu bir özelliği oluşturmak "yapılan iş" olarak sayılır ve kullanım kolaylığı gibi bir kullanıcı hedefinden uzaklaşan bir iş biriminin tamamlanması, istenen yönün tersine harekettir. Bu, "hız" yapar. Agile'da daha çok fiziğin yönsüz “hızı” kavramı gibi.[kaynak belirtilmeli ]
Hızla ilgili üçüncü bir sorun, genellikle verimlilik veya takım performansının bir ölçüsü olarak kötüye kullanılmasıdır. Hız, verimlilik değil, yapılan işin bir metriğidir. Hız, fazla mesai yapılarak veya ekip üyeleri eklenerek artırılabilir, bunların ikisi de verimliliği veya performansı artırmaz.[kaynak belirtilmeli ]
Özetle, hız sorunlu bir ölçüdür çünkü manipüle edilmesi kolaydır ve çoğu zaman bir verimlilik göstergesi olarak kötüye kullanılır.[kaynak belirtilmeli ]
Referanslar
- ^ a b Rubin Kenneth (2013), Temel Scrum. En Popüler Çevik Süreç için Pratik Bir Kılavuz, Addison-Wesley, ISBN 978-0-13-704329-3
- ^ Boyut ölçüleri, agilesoftwaredevelopment.com, arşivlenen orijinal 2010-10-26 tarihinde, alındı 2010-09-24
- ^ Scrum terimleri sözlüğü: Hız, dan arşivlendi orijinal 2010-11-29 tarihinde, alındı 2010-09-24
- ^ Çevik 101: Çevik Yazılım Geliştirme Hızı, VersionOne.com, arşivlendi orijinal 2010-10-02 tarihinde, alındı 2010-09-23
- ^ "nokta enflasyon". innolution.com. Alındı 2019-06-06.