Çevik Hikaye Puanları ve Saatler: Yazılım Geliştirme Nasıl Daha İyi Tahmin Edilir

Zihninizi yazılım geliştirme süreçlerine sarmak zor olabilir. Bir fikir ortaya attığınızda ve onunla geliştiricilere yaklaştığınızda, sorduğunuz ilk iki şey , uygulamanın ne kadara mal olacağı ve inşa etmenin ne kadar zaman alacağıdır . Tahmin, uygulama geliştirmedeki ilk adımlardan biridir.

Bu makalede, modern yazılım geliştirmede en popüler iki tahmin modelini karşılaştırıyoruz: Çevik hikaye noktaları ve saatler .

Çevik'te zamanı nasıl tahmin edeceğinizi öğrenmek, her iki tahmin modelinin özünü öğrenmek, farklılıklarını anlamak ve geliştiricilerin neden birini diğerine tercih edebileceğini görmek için okumaya devam edin.

Saatleri anlamak oldukça kolaydır ve uzun süredir yazılım geliştirmede birincil tahmin modeli olmuştur. Adam-saat veya işçi-saat olarak da bilinen saatler, bir geliştiricinin projede harcadığı saat sayısıdır .

Öyleyse hikaye noktaları nelerdir ve zaten basit ve anlaşılır bir tahmin modelimiz varsa neden ortaya çıktılar?

İçindekiler:

1. Hikaye noktaları tam olarak nedir?
2. Çevik'te hikaye puanlarının nasıl hesaplandığı aşağıda açıklanmıştır
3. Hikaye noktalarında tahmin yapmanın avantajları
4. Hikaye puanlarını tahmin etmenin dezavantajları
5. Saat cinsinden tahmin yapmanın avantajları
6. Saat cinsinden tahmin etmenin dezavantajları
7. Hikaye puanlarını saatlere çevirebilir misin?
8. Hikaye puanları ve saatler: Yazılım geliştirme için ne seçilir?

Hikaye noktaları tam olarak nedir?

Öykü puanları, Agile ve Scrum'a özgü göreceli bir tahmin modelidir. Geliştirmenin üç yönünü ele alarak bir ürün oluşturma çabasını tahmin ederler:

• ürünün gerektirdiği iş miktarı

• ürün özelliklerinin karmaşıklığı

• gelişmeyi etkileyebilecek riskler ve belirsizlikler

Proje değerlendirmesinin en başında geliştiriciler, bir ürünün sahip olduğu en küçük ve en basit kullanıcı hikayesini (örneğin, kaydolan bir kullanıcı hikayesi) seçer ve bunu 1 noktalı bir kullanıcı hikayesi olarak ayarlar. Temel hikaye budur : karmaşıklık karşılaştırmaları için kullanılacak bir kullanıcı hikayesi. Diğer tüm kullanıcı hikayelerine, temel hikayeye kıyasla ne kadar karmaşık geliştireceklerine bağlı olarak bir dizi hikaye puanı atanacaktır.

Yüzeyde yeterince basit görünüyor, ancak her hikayedeki hikaye noktalarının sayısına kim karar veriyor?

Agile'da hikaye puanlarının nasıl hesaplandığı aşağıda açıklanmıştır

Saatlerde olduğu gibi, ürün üzerinde çalışacak kişiler genellikle geliştirme için hikaye noktalarını tahmin eder. Ancak, tahmin süreci hikaye noktaları ile biraz farklıdır.

Bir kullanıcı hikayesine hikaye noktaları atamak için birkaç geliştirici dahil edilir. En az iki tane olmalı, ancak şirket tüm geliştiricilerinden endüstrinin Planning Poker dediği şeyi oynayarak katkıda bulunmalarını isteyebilir. İşte oyunun kuralları:

1. Her geliştiriciye bir dizi Planning Poker kartı verilir.

2. Geliştiriciler bir kullanıcı hikayesi seçer ve bunun karmaşıklığını ve gereken geliştirme çabasını tartışır.

3. Her geliştirici, hikayeye atayacakları puan sayısına karşılık gelen bir kart öne sürer.

4. Hikaye puanı tahminleri aynıysa, hikayeye tahmini puan sayısı atanır.

5. Önerilen hikaye noktaları farklıysa, geliştiriciler, çoğunluk tarafından onaylanan bir dizi nokta bulana kadar kullanıcı hikayesini tartışır.

6. Geliştiriciler bir sonraki kullanıcı hikayesini seçer.

7. 3'ten 5'e kadar olan adımları tekrarlayın.

Faaliyetlerimizin tümü uzaklaştığında, bu süreç değiştirildi. Kartlar ve toplantılar yerine hikaye noktalarına çevrimiçi tartışmalarda, Zoom toplantılarında veya habercilerde karar verilir.

Şuna benziyor:

Bu, elbette, hikaye noktalarını tahmin etmeye dahil olan tüm geliştiricilerin proje üzerinde çalışacağı anlamına gelmez. Ancak hikaye puan sisteminin önemli bir avantajı, sadece söz konusu projede değil, benzer özelliklere sahip gelecekteki projelerde de kullanılabilecek az çok evrensel bir çerçeve oluşturmasıdır.

Hikaye noktalarını tahmin etmek için sık kullanılan iki seçenek vardır. Puan atayabilirsiniz:

• herhangi bir tam sayı (1, 2, 3… 13,14,15, vb.)

• Fibonacci dizisindeki sayıları kullanarak (1, 2, 3, 5, 8, 13… 55, 89, 144, vb.)

Fibonacci dizisi, yaklaşıklık için bir miktar marj bıraktığı için gelişimi tahmin etmek için daha uygun bir seçenektir. Sayısal sıra modeli, uygun karşılaştırmalar için biraz fazla hassastır.

Geliştirme sırasında ve projeler arasında, kullanıcı hikayesi başlangıçta tahmin edilenden daha fazla veya daha az karmaşık hale gelirse, atanan hikaye noktaları değiştirilebilir.

Hikaye noktalarında tahmin yapmanın avantajları

Hikaye puanları atama süreci biraz karmaşık görünüyorsa, sizi atmasına izin vermeyin. Hikaye noktaları ile kapasite planlamasının avantajları vardır.

1. Hikaye puanları geliştiriciden bağımsızdır

Her hikaye için hikaye puanları , pazarlıkta birkaç geliştirici tarafından atanır ve bunun nedeni, sayının yalnızca belirli bir ürün ve belirli bir geliştirici için değil, "ortalama olarak" atanmasıdır. Bu neden iyi bir şey?

Olur böyle şeyler. Bazen projenizin geliştiricisi projenizden ayrılabilir ve yerini alabilir. Belki hastalanacaklar, ebeveyn izni ya da izin almaya karar verecekler ya da şirketten ayrılacaklar. Belki de proje için yetersiz veya fazla kalifiye olacaklar.

Değiştirildiklerinde, yeni bir geliştirici farklı bir çalışma hızına sahip olabilir , bu da ürünü oluşturmak için gerekli çalışma saatlerinin yeniden tahmin edilmesine yol açar.

Hikaye noktaları bu sorunu en aza indirir . Birkaç farklı geliştirici tarafından atanarak, belirli bir kullanıcı hikayesinin ne kadar karmaşık olduğuna genel bir bakış sağlarlar. Hikaye puanları, belirli bir şirketteki tüm geliştiriciler için çalışır. (Fakat hikaye puan tahminlerinin farklı şirketler için doğru olmayacağını lütfen unutmayın.)

2. Hikaye puanları, geliştirme süresini yeniden hesaplamayı kolaylaştırır

Hikaye puanlarıyla Çevik zaman tahmininde takımlar, tek bir sprintte yayınlanan hikaye noktalarının sayısını belirtmek için hız terimini kullanır.

Takımlar hızlarını sürekli olarak izler ve başlangıçta oldukça değişkendir. Bir takım, bir hafta beş hikaye puanı ve bir sonraki hafta yirmi hikaye puanı değerinde özellikler yayınlayabilir. Ama bu sadece başlangıçta. Proje ilerledikçe, hız grafiği eşit olacaktır .

Saatlerle birlikte, bir ekip üyesi değişirse, son teslim tarihlerini ayarlamak için dahil oldukları her görevin yeniden tahmin edilmesi gerekir. Hikaye puanları söz konusu olduğunda bu gereksizdir - ekip, genel hızdaki değişikliği bilerek bir sonraki sprintten sonra proje son tarihini ayarlayabilir.

Hikaye puanları, ekip performansını bir bütün olarak değerlendirerek göreve göre yeniden tahmin etme ihtiyacını ortadan kaldırır.

3. Hikaye puanları, ekip performansını izlemek için iyidir

Farklı zamanlarda benzer projeler ve/veya görevler üzerinde çalışan ekipleriniz olduğunda, hız size her ekibin kaydettiği ilerlemeyi kolayca gösterebilir. İyileştiler mi ve ne kadar? Hangi takım veya geliştiriciler mücadele ediyor ve ekstra eğitime ihtiyaç duyabilir? Öğrenme eğrisi nedir? Belki farklı bir takım daha iyi performans gösterir?

Velocity, takımlarınızın performansını sadece yerinde değil, sürekli olarak değerlendirmek için harika bir araçtır.

4. Hikaye puanlarıyla başlatma zamanı tahmini daha kesindir

Ekip, hızı takip ederek, bir sprintte kaç tane hikaye noktası yayınlayabileceklerini yüksek hassasiyetle bilir. Uygulama geliştirme ekibinin hızını hesaplaması biraz zaman alsa da, hesaplandıktan sonra tahmini başlatma tarihini tahmin etmek kolaydır .

Ayrıca, ekip üyelerindeki değişiklikler, gereksinimler veya özelliklerin sayısı/karmaşıklığı, yeniden tahminde pek çok mücadeleye neden olmaz.

5. Tahmini hızlandırmak için gelecekteki projeler için hikaye noktalarını yeniden kullanabilirsiniz.

Bir şirketin belirli bir niş (veya birkaç) konusunda bilgili olması ve benzer özelliklere sahip birden fazla ürün oluşturması nadir değildir. Hikaye noktalarında tahmin edilen bir projeyi bile tamamladıktan sonra, geliştiriciler yeni projeler için bu tahmine başvurabilirler . Bu, tahmin süresini kısaltacaktır.

Ancak, koşullar değişebileceğinden, her proje için hızı izlemeye devam etmek önemlidir.

6. Hikaye puanları ekip çalışmasını geliştirir

Geleneksel olarak, geliştirme şirketlerinin her biri ayrı projeler üzerinde çalışan birkaç geliştirici ekibi vardır. Saat cinsinden tahmin yaparken, tahminde bulunan proje üzerinde çalışan geliştiricidir. Bu genel olarak iyi bir şey, çünkü bir şeyin ne kadar süreceğini, onu yapan kişiden daha iyi kim bilebilir?

Bununla birlikte, hikaye noktalarındaki karmaşıklığı tahmin etmek , aynı alandaki geliştiricilere işbirliği yapma fırsatı sunar - nadiren gerçekleşen bir şey. Bu tür bir ekip çalışması, deneyimleri paylaşmak ve birbirimizi motive etmek için büyük bir şans sağlar.

Hikaye puanlarını tahmin etmenin dezavantajları

Tartışmanın her zaman diğer tarafı vardır, bu da büyük sistemlerin nasıl doğduğudur. Karmaşıklığa dayalı tahminin dezavantajları da vardır ve her takım, avantajlarından daha ağır basıp basmayacağına kendileri karar vermelidir.

1. Hikaye puanları birden fazla geliştirici tarafından atanmalıdır

Öykü puanları modelinin satış noktası, nesnelliği ve gelecekteki tahminler için değeridir. Ancak bunun doğru olması için tahminin birden fazla geliştirici tarafından yapılması gerekir . Tek bir ekibe sahip küçük şirketler veya bir alanda yalnızca bir uzmanın bulunduğu (yani yalnızca bir tasarımcı veya iOS geliştiricisi) şirketler için hikaye puanları pek fazla avantaj sağlamaz. Bu tür küçük şirketler geleneksel olarak bir tahmin modeli olarak işçi saatlerini seçerler.

2. Hikaye noktalarındaki tahmin, hatırı sayılır bir birikim gerektirir

Hikaye noktalarının tam potansiyelini gerçekleştirmek için ekibinizin önemli miktarda zaman harcaması gerekecek. Ekibin daha önce üzerinde hiç çalışmadığı (veya tam zamanlı çalışmadığı) özelliklere sahip bir proje üzerinde çalışıyorsanız, ilk iki ila üç sprint'i performans açısından tahmin etmek zor olacaktır. Kabul edilirse, ekipleriniz ne kadar fazla birikim kalemine sahipse, istatistiksel verilerin bolluğu nedeniyle tahminleri o kadar kesin olabilir. Ancak hikaye noktaları hemen kullanıma hazır bir sistem değil.

3. Hikaye noktaları bütçeleme için daha karmaşıktır

Hikaye noktaları, geliştiriciler ve müşterinin pazarlaması için önemli olabilecek kesin son tarihler ve lansman tarihleri ​​belirlemek için mükemmeldir. Ancak, uygulama geliştirme maliyetlerinin tahmin edilmesi söz konusu olduğunda, bunlar daha az kullanışlıdır .

Mesele şu ki, geliştiriciler bir projeye yalnızca kod yazmak (veya tasarım yapmak veya test etmek) için zaman harcamazlar. Ekip içinde ve müşteriyle birlikte araştırma, tartışma, değişiklik yapma vb. için biraz zaman harcanır. Hikaye puanlarını tahmin etmek için harcanan zaman aynı zamanda proje için harcanan zamandır, ancak hikaye başına puanlara dahil edilmez.

Hikaye puanlarını tahmin ederken bütçe yapmak mümkündür, ancak parayı projeye harcanan zamana eşitlemek genellikle daha hızlı ve daha kolaydır.

4. Hız, takım başına hesaplanır

Bunun anlamı, ekipler projeler arasında karışırsa, her geliştirici kombinasyonu için hızı ayrı ayrı hesaplamanız gerekir. Bu nedenle, bir takım için yapılan tahmin, farklı bir takım için mutlaka doğru olmayacaktır ve tek bir takım üyesini değiştirmek bile, önceki tahminleri potansiyel olarak geçersiz kılabilir.

Öte yandan, en iyi performans gösteren kombinasyonları bulmak için karmaşıklık tahminini kullanabilirsiniz. Yine de zaman alacak.

Saat cinsinden tahmin yapmanın avantajları

Bazı Çevik ekipler hikaye puanlarını kullanırken, birçoğu henüz çalışma saatlerinden geçiş yapmadı. Bunun önemli nedenleri var. Onları da kaplayalım.

1. Saat tanıdık bir modeldir

Yenilik harikadır, ancak zaman alır. Geliştiriciler ve müşterileri, işçi-saat tahmini konusunda oldukça bilgilidir. Birçokları için fikir “bozuk değilse tamir etme” şeklindedir. Sistem uygulanabilir tahminler sunduğu sürece, neden başka bir şeye geçelim?

Tahminlerin kesinliğindeki fark, bazı geliştiricilerin işleri nasıl yaptıklarını değiştirmeleri için yeterince büyük olmayabilir.

2. Müşteriler genellikle saatlerce ödeme yapar

Bunun biraz detaylandırılması gerekiyor. Müşteriler için karmaşıklığa dayalı tahmin kafa karıştırıcı olabilir . Ayrıca, müşteri için bütçe lansman tarihinden (ki çoğu zaman öyledir) daha önemliyse, hikaye puanları onlar için alakalı olmayacaktır.

3. Saate dayalı tahmin tek bir geliştirici tarafından yapılabilir

Küçük ekipler veya serbest çalışanlar için hikaye noktaları, birden fazla bakış açısı gerektirdiğinden büyük ölçüde işe yaramaz. Herhangi bir referans olmadan, hikaye noktalarını tahmin etmek gereksiz bir güçlüktür.

Saatler ise proje üzerinde çalışan geliştiriciye kendileri oldukça kesin tahminler yapmaları için bir yol sunar.

Aynı şey takım hızı için de geçerli. Serbest çalışanlarda veya kısmi dış kaynak kullanımında olduğu gibi ekipler her seferinde değiştiğinde, hızı izlemek çok az mantıklıdır. Saate dayalı tahmin burada daha iyi bir seçimdir.

Saat cinsinden tahmin etmenin dezavantajları

İşte ekiplerin saatleri bir tahmin modeli olarak kullanmayı bırakmaya karar vermelerinin nedenleri.

1. Tahminden yalnızca sorumlu olmak çok fazla baskıdır

Bir yandan, yalnızca kendinize güvendiğiniz için kendi zaman gereksinimlerinizi tahmin etmek daha kolay olabilir.

Öte yandan, tahminlerinizi gerçekleştiremezseniz, bu büyük bir darbe olur. Dahası, görevlerine başlamak için bekleyen ekip sizinkini tamamlamanıza bağlıysa.

Ayrıca, söz verdiğiniz şeyi yerine getirme baskısının neden olduğu stres, aksi takdirde iyi giden bir görevi bozabilir.

2. Bir geliştiricinin tahmini her zaman bir ekibin tahmininden daha az kesindir.

Bireysel tahminler özneldir ve tahmincinin duygusal ve psikolojik koşullarına bağlıdır.

Bazı geliştiriciler kendilerini abartma ve daha sonra sürdürmekte zorlandıkları zaman dilimleri belirleme eğilimindedir . Bu sadece gelişimi bozmakla kalmaz (ve cezalar varsa ekibe ekstra maliyet getirir) aynı zamanda geliştiricilerde strese ve tükenmeye neden olur .

Diğerleri kendi becerilerini hafife alır , gelişimi nesnel olarak ihtiyaç duyulandan daha fazla uzatır. Güvensizlik ve işi gereğinden fazla düşünme, kontrol etme ve yeniden kontrol etme alışkanlığı genellikle geliştirme son tarihlerinin daha sonraki tarihlere ayarlanmasına yol açar ve görevler nadiren son teslim tarihlerinden önce tamamlanır . Ekip girişi, daha objektif bir tahmine izin verir.

3. Görev ne kadar büyükse, saat cinsinden tahmin etmek o kadar zor olur

Bu gelişme olmayan durumlarla da ilişkilidir. Üç sayfalık bir üniversite kitapçığını okumanın ne kadar zaman alacağını söylemek kolay ama Savaş ve Barış'ı bitirmenin ne kadar süreceğini tahmin etmek daha zor.

Aynı şey gelişme için de geçerli. Biraz deneyime sahip geliştiriciler için küçük görevlerin tahmin edilmesi kolaydır . Ancak görev ne kadar büyük olursa, hem projenin içinde hem de dışında gerçekleşen daha fazla şey gelişmeyi etkileyebilir. Saate dayalı tahminler, hikaye noktalarının sahip olduğu marjları sunmaz, bu da tahminleri daha zor hale getirir.

4. Az esneklik

Saate dayalı tahmin, geliştiriciye dayalıdır. Ürün üzerinde çalışan bir ekip üyesi projenin ortasında değişirse, ekibin hala geliştirme aşamasında olan veya gelecekteki sprintler için planlanan her etkilenen kullanıcı hikayesini yeniden hesaplaması gerekecektir. Projenin bulunduğu aşamaya ve orijinal ile yeni geliştirici arasındaki beceriler arasındaki farka bağlı olarak bu çok fazla iş olabilir. Saate dayalı zaman tahmini oldukça katıdır.

Hikaye puanlarını saatlere çevirebilir misin?

Müşteriler hikaye noktalarında tahminler yapan bir ekipten Agile hikaye noktaları haritalamasını saatlere dönüştürmesini isteyebilir. En son yazılım geliştirme eğilimlerine aşina olmayan çoğu insan, hikaye noktalarından ne çıkaracağını bilemez.

Bununla birlikte, bir müşteri bir hikaye puanının kaç saat olduğunu sorduğunda, kesin olarak cevap vermek imkansızdır. Karmaşıklığa dayalı tahminin temel bileşenlerinden biri, hikayeyi tamamlamak için harcanan çabadır. Ancak çaba, doğrudan harcanan zamana dönüşmez . Saatler, belirsizliği hikaye noktalarından daha belirsiz bir şekilde ele alır.

Görev ne kadar karmaşıksa, belirsizlik ve riskler o kadar fazladır. Riskler ve belirsizlikler söz konusu olduğunda saate dayalı tahmin, hikaye noktalarından daha yaklaşık olduğundan, hikaye noktalarını basit bir şekilde saatlere dönüştürmek ve yalnızca hıza güvenmek bu tür birçok riski hesaba katmaz.

Bir dereceye kadar, hikaye noktaları atamada Fibonacci dizisini kullanmak, geliştirme sürelerindeki belirsizliği hesaba katacaktır, ancak tam olarak doğrudan bir dönüşüme izin vermez.

İşte bir örnek.

1 katlı noktalı bir hikayenin (temel hikaye) tamamlanması, diyelim ki iki saat sürer.

Bir 13 katlı noktası hikayesi en iyi senaryoda 26 saat sürebilir - hiçbir şey ters giderse veya bir şekilde alırsa. Örneğin, kullanılan API sorunsuz bir şekilde uyuyorsa, uç noktadan uç noktaya. Ancak olmazsa, hikaye, kaç tane uyumsuzluk olduğuna bağlı olarak, 30 ila 50 saat arasında bir süre gerektirebilir. Geliştirici, söz konusu API ile henüz çalışmadıysa, nasıl gideceğini kimse önceden söyleyemez.

Bu nedenle, hikaye noktalarını saatlere çevirirken, belirsizliği gidermek için üstel büyüme için bir çarpan olması gerekir. Ve bu çarpan bir takımdan diğerine farklılık gösterecektir.

Hikaye puanları ve saatler: Yazılım geliştirme için ne seçilir?

Gördüğünüz gibi, hem hikaye noktaları hem de saatler, bir geliştiricinin projeleri tahmin etmesi için geçerli seçeneklerdir.

Sonuç olarak, daha fazla ürün şirketinin hikaye noktalarını seçtiğini, taşeronların ise saatlere dayanma eğiliminde olduğunu söyleyebiliriz.

Sabit fiyat modeli ile çalışan şirketler genellikle saat bazlı tahminde bulunurlar. Scrum'ı tercih eden takımlar, kelimenin tam anlamıyla Scrum'dan doğdukları ve bu metodolojiye özgü oldukları için genellikle hikaye noktalarını seçerler.
Yılların deneyiminde, bunu şu şekilde görmeye geldik:

• Lansman tarihini doğru bir şekilde tahmin etmek, bütçeye uymaktan daha önemliyse, hikaye noktalarına gidin.

• Bütçe, doğru bir lansman tarihinden daha önemliyse saatleri göz önünde bulundurun.

Ya da en iyisi ikisini birleştirin.

Hikaye noktaları , izleme hızının fark yaratacağı uzun projelerde çalışan geliştirme ekipleri için oldukça uygundur.

Saatler bütçelerinin içine sıkma dert müşteriler için önemlidir. Ayrıca, kısa vadeli projeler için saatler daha anlamlıdır.

Karmaşıklık tabanlı sistem, Scrum'ın kendisi gibi hala oldukça genç ve hala gelişiyor. Her iki tahmin modelini birleştirmek ve her bir hikaye noktasını saatlere hızlı bir şekilde değiştirmek için bir sistem geliştirmek, dezavantajları en aza indirirken her iki modelin de faydalarını sağlar.