Geliştirmede Hikaye Puanları — nedir, değerlendirme ölçekleri ve uygulama
Hikaye puanları, çevik geliştirme metodolojilerinde görevlerin karmaşıklığını ölçmek için kullanılan göreceli birimlerdir. Saatlerin aksine, hikaye puanları yalnızca zamanı değil, aynı zamanda bir görevin karmaşıklığını, risklerini ve belirsizliğini de hesaba katar. Scrum.org, 2023'e göre, hikaye puanlarında göreceli tahmin kullanan ekipler, saat olarak tahmin yapan ekiplere kıyasla sprint teslim tarihlerini %25 daha az kaçırır.
Kilit Noktalar
- Hikaye puanları — görev karmaşıklığının göreceli birimleri, zamana bağlı değildir.
- Temel ölçekler — Fibonacci (1, 2, 3, 5, 8, 13, 21) ve doğrusal (1, 2, 3, 4, 5).
- Velocity — bir ekibin sprint başına tamamladığı hikaye puanı sayısı, tahmin için kullanılır.
- Ana avantaj — hikaye puanları belirli bir geliştiriciye bağlı değildir ve ekip için karmaşıklığı yansıtır.
- Kilit kural — referans görev ölçeği tanımlar: ekip 1 hikaye puanının ne anlama geldiği konusunda anlaşır.
Hikaye puanları nedir?
Hikaye puanları, Scrum ve diğer çevik metodolojilerde kullanılan bir görev karmaşıklığı metriğidir. Ekip her görevi saat olarak değil, göreceli birimler halinde değerlendirir: “bu görev referanstan iki kat daha karmaşık.” Bu yaklaşım, farklı geliştiriciler arasındaki hız farkını dengeler ve karmaşıklığa odaklanır.
Terimin kökeni
Hikaye puanları kavramı, 2000'lerin başında Scrum'ın popülerleşmesiyle ortaya çıktı. Yöntemi tanımlayan ilk kişilerden biri, Extreme Programming (XP) kapsamında Ron Jeffries'di. Fikir, her zaman yanlış olan “adam-saat” tahmininden, ekibin toplu olarak belirlediği göreceli karmaşıklığa geçmekti. Bugün, hikaye puanları çevik ekipler için endüstri standardıdır.
Hikaye puanlarında dikkate alınan faktörler
Hikaye puanlarıyla tahmin yaparken ekip üç faktörü dikkate alır: iş hacmi (kod, ekran, mantık miktarı), karmaşıklık (teknik zorluklar, yeni teknolojiler) ve belirsizlik (net olmayan gereksinimler, riskler). Bir hikaye puanı “risksiz basit bir görev” anlamına gelebilirken, 8 “yüksek belirsizlikli karmaşık bir görev” anlamına gelebilir.
Hikaye puanı ölçekleri: nasıl seçilir
Hikaye puanı ölçeği seçimi, tahmin doğruluğunu ve planlama kolaylığını etkiler. En popüler ölçek Fibonacci dizisidir, ancak alternatifler de vardır.
| Ölçek | Değerler | Avantajlar | Dezavantajlar |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Büyük görevlerde doğal dağılım artışı | Yeni ekipler için zor |
| Doğrusal | 1, 2, 3, 4, 5 | Basit ve anlaşılır | Büyük görevler için dağılım yok |
| Kuvvet | 1, 2, 4, 8, 16, 32 | Büyük görevler için maksimum dağılım | Büyük görevleri ayırt etmek zor |
| Tişört | S, M, L, XL | Hızlı kabaca tahmin | Hassas değil, dönüşüm gerekli |
Neden Fibonacci? Ölçeğin psikolojisi
Fibonacci dizisi tesadüfen seçilmemiştir. 1 ve 2 arasındaki fark minimumdur (%50), 13 ve 21 arasındaki fark ise önemlidir (%62). Bu gerçeği yansıtır: küçük görevler daha doğru tahmin edilir, büyük görevler daha büyük dağılımla tahmin edilir. Bir görev 21 hikaye puanı olarak tahmin edildiğinde, ekip şunu anlar: “ne kadar süreceğini bilmiyoruz, ancak kesinlikle 13'ten fazla.” Fibonacci ölçeği yanlış kesinliği önler.
Referans görev — ölçeğin temeli
Ölçeğin çalışması için ekip bir referans üzerinde anlaşır: “X görevi 1 hikaye puanıdır.” Genellikle basit, iyi bilinen bir görev referans olarak seçilir: “ekrana metin alanı eklemek” veya “bir yazım hatası düzeltmek.” Diğer tüm görevler referansa göre tahmin edilir. Referans olmadan, hikaye puanları anlamını kaybeder — herkes birimi farklı anlar.
Ekip velocity'si ve tahmin
Velocity, bir ekibin sprint başına tamamladığı ortalama hikaye puanı sayısıdır. Bu, proje zaman çizelgelerini tahmin etmek için önemli bir metriktir.
Velocity nasıl hesaplanır
Velocity, tamamlanan görevlere göre hesaplanır: ekibin bitirmeyi başardığı tüm görevlerin (tamamlama tanımı karşılanan) hikaye puanları toplanır. Tamamlanmayan görevler sayılmaz. Doğruluk için son 3-5 sprintin ortalaması alınır. Örneğin, bir ekip son 4 sprintte 20, 22, 18 ve 24 hikaye puanı tamamladıysa, velocity = 21 hp'dir.
Velocity aracılığıyla tahmin
Velocity ve backlog'un toplam hikaye puanı hacmini bilerek, yayına kadar geçecek sprint sayısını tahmin edebilirsiniz. Örneğin, backlog'da 210 hikaye puanı varsa ve velocity = 21 ise, 10 sprint gerekir. Bu, çalışma ilerledikçe iyileştirilen kaba bir tahmindir. Önemli: velocity bir ortalamadır, taahhüt değildir. Ortalama yerine alt sınıra (18 hp) göre plan yapın.
Velocity nasıl artırılır
Velocity emirle artırılamaz — süreç sağlığının bir belirtisidir. Sürdürülebilir velocity büyümesi şu yollarla elde edilir: teknik borcu azaltmak, kod inceleme süreçlerini iyileştirmek, bağlam değiştirmeyi azaltmak, test ve CI/CD'yi otomatikleştirmek. Önemli: farklı ekiplerin velocity'si karşılaştırılamaz — her ekip hikaye puanlarını kendi yöntemiyle tanımlar.
Hikaye puanları vs saat: ne ve ne zaman kullanılmalı
Hikaye puanları ve saatler farklı amaçlara sahiptir ve aralarındaki seçim bağlama bağlıdır. Deneyimli ekipler, farklı görevler için her iki yaklaşımı da kullanır.
Hikaye puanları ne zaman daha iyi çalışır
Hikaye puanları sprint planlaması için vazgeçilmezdir: görevi kimin yapacağına bağlı değildir. Bir junior günde 2 hp yapabilir, bir senior 4 hp, ancak görev tahmini her ikisi için de 2 hp olarak kalır. Hikaye puanları, geliştiricileri karşılaştırmadan ekip üretkenliğini izlemeye olanak tanır. Bu, politik baskıyı azaltır ve ekip atmosferini iyileştirir.
Saatler ne zaman gereklidir
Saatler dış taahhütler için gereklidir: sözleşmeler, bütçeler, müşteri raporları. Bir müşteri “8 hikaye puanı” değil, “3 hafta” bilmek ister. Hikaye puanlarını saate dönüştürmek için geçmiş dönüşüm oranını kullanın: ekip, 1 hp'nin yaklaşık 4 saatlik çalışmaya eşit olduğunu bilir. Dönüşüm şeffaf ve veriye dayalı olmalı, tahmine değil.
Kombine yaklaşım
Birçok ekip kombine bir yaklaşım kullanır: görevler sprint planlaması için hikaye puanlarıyla tahmin edilir ve ardından yönetici dış raporlama için bunları saate/güne dönüştürür. İki sistemi tek bir süreçte karıştırmamak önemlidir: ya hikaye puanlarıyla tahmin edip velocity'den zamanı çıkarırsınız ya da doğrudan saat olarak tahmin edersiniz.
Hikaye puanlarıyla çalışırken yaygın hatalar
Hikaye puanlarının uygulanmasına genellikle göreceli tahminin faydalarını ortadan kaldıran hatalar eşlik eder. İşte en yaygın olanları.
Hikaye puanlarını zamana bağlamak
En yaygın hata — ekip şu konuda anlaşır: “1 hp = 4 saat.” Bu durumda, hikaye puanları anlamını kaybeder ve farklı bir adla saatlere dönüşür. Hikaye puanları göreceli olmalı, zamana bağlı olmamalıdır. A görevi B görevinden iki kat karmaşıksa, kaç saat süreceğine bakılmaksızın 2 hp alır.
Geriye dönük tahmin
Bir görev tamamlandıktan sonra tahmin edildiğinde — bu tahmin değil, kayıttır. Hikaye puanları, işe başlamadan önce, maksimum belirsizlik anında atanmalıdır. Geriye dönük tahmin, velocity'yi bozar ve planlama için hiçbir fayda sağlamaz. Ayrıca, yanlış bir kesinlik hissi yaratır.
Ekipler arasında velocity karşılaştırması
A takımı ve B takımının velocity'sini karşılaştırmak anlamsız bir alıştırmadır. Her ekip referansı ve ölçeği farklı tanımlar. Bir ekip için 1 hp, bir saatlik basit bir görevken, diğeri için bir günlük bir görevdir. Yalnızca aynı ekibin zaman içindeki velocity'sini karşılaştırabilirsiniz: artıyor mu azalıyor mu.
Tutarsız ölçek
Aynı karmaşıklıktaki farklı görevler farklı hikaye puanları aldığında ve daha karmaşık olanlar daha az puan aldığında, ölçek bozulur. Ekip, ölçeği düzenli olarak kalibre etmelidir: her 3-6 sprintte bir, tahminlerin gerçek karmaşıklıkla ne kadar örtüştüğünü geriye dönük olarak gözden geçirin. Bu, tahminlerin tutarlılığını artırır.
Sıkça Sorulan Sorular
Bir hikaye puanında kaç saat vardır?
Hikaye puanlarının saat olarak sabit bir karşılığı yoktur. Göreceli bir birimdir: 1 hp = referans görevin karmaşıklığı. Saatlere dönüştürmek için ekibinizin geçmiş dönüşüm oranını kullanın: sprint başına çalışılan ortalama saat sayısını velocity'ye bölün. Genellikle 1 hp = 4-8 saat, ancak bu her ekip için farklılık gösterir.
Kanban'da hikaye puanları kullanılabilir mi?
Evet, hikaye puanları Kanban'da kullanılabilir, ancak bazı uyarılarla. Kanban'da sabit sprintler yoktur, bu nedenle velocity bunun yerine hafta veya ay bazında hesaplanır. Kanban ekipleri genellikle hikaye puanları yerine Çevrim Süresi'ni kullanır — bir görevin baştan sona geçen süresi. Seçim, ekibin özelliklerine bağlıdır.
Ekip bir tahmin üzerinde anlaşamazsa ne yapılmalı?
Tahminler farklıysa (biri 3 hp, diğeri 13 hp veriyor), bu görevin iyi anlaşılmadığının bir işaretidir. Görevi daha küçük parçalara ayırın. Farklı geliştiricilerin gördüğü riskleri ve belirsizlikleri tartışın. Görev büyükse, hikaye puanları yerine bir Spike (2-4 günlük araştırma) olarak tahmin edin.
Saat olarak tahmin yapmayı bırakıp hikaye puanlarına nasıl geçilir?
Geçiş 3-6 sprint sürer. Bir ölçek seçerek (Fibonacci en güvenli seçimdir) ve bir referans görev tanımlayarak başlayın. 2-3 Planning Poker oturumu düzenleyin. Her sprintten sonra velocity'yi hesaplayın. Hikaye puanlarını saate dönüştürmeyin — ekibin yeni sisteme alışmasına izin verin. 3 sprint sonra planlamanın ne kadar iyileştiğini göreceksiniz.
Bir görevin hikaye puanı tahmini tamamlandıktan sonra değişir mi?
Hayır, tahmin değişmez. Hikaye puanları, işe başlamadan önce yapılan ön bir karmaşıklık tahminidir. Görev tamamlandıktan sonra, gerçek çaba farklı olsa bile tahmin aynı kalır. Tahmini geriye dönük olarak değiştirmek istatistikleri bozar ve tahmin amacını geçersiz kılar. Retrospektiflerde tutarsızlıkları analiz edin, ancak tahminleri geriye dönük olarak değiştirmeyin.
Özet
- Hikaye puanları — karmaşıklığın göreceli birimleri, zamana bağlı değil, çevik tahminin temeli.
- Temel ölçekler — Fibonacci (önerilen), doğrusal, kuvvet, tişört boyutlandırması.
- Velocity — sprint başına hikaye puanı sayısı; zaman çizelgesi tahmini için ana metrik.
- Hikaye puanları vs saat — sprint planlaması için hikaye puanları, dış taahhütler için saatler.
- Yaygın hatalar — zamana bağlama, geriye dönük tahmin, ekip karşılaştırması, tutarsız ölçek.
- Referans görev — ölçeğin temeli; onsuz hikaye puanları anlamını kaybeder.
- Ana avantaj — hikaye puanları bireye bağlı değildir ve ekip üretkenliğine odaklanmayı sağlar.
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun