Çevikte Hikaye Puanları Nelerdir ve Nasıl Tahmin Edilir?

Yayınlanan: 2021-06-17

İçindekiler

Agile'da Hikaye Puanları nedir?

Hikaye noktaları, Scrum ve eXtreme Programlama gibi çevik çerçevelerin uygulanması yoluyla gerçekleştirilen işi tahmin etmek için bir ölçümdür.

Bir kullanıcı hikayesinin uygulanması, başarılması zor bir iştir. Takım risklerle karşı karşıya kalabilir; geliştirme sürecindeki karmaşıklıklar vb. Bu zorluk seviyesi, geliştirme ekibi tarafından hikaye noktası adı verilen soyut bir ölçü kullanılarak ölçülür. Bu nedenle, Agile'daki hikaye noktaları, çevik geliştirmede metrik olarak kullanılır. Takıma hikayenin uygulanmasının ne kadar zor olduğunu anlatır.

Ürün biriktirme listesi bakım oturumları, daha sonra ürün geliştirme ve test ekibi tarafından değerlendirilen hikaye noktalarının tahminini gerçekleştirir. Bu, sprint planlamasının verimliliğini artırmak için yapılır. Ürün biriktirme listesi düzeltmesi, aşağıdakileri kontrol eden kaba bir tahmindir:

  • Sprint planının verimli bir şekilde yürütülmeye hazır olup olmadığı.
  • Konuları tamamlamak için bilgi yeterli mi?
  • Kullanıcı hikayesine dayalı sprint planının makul olup olmadığı.

Çevik hikaye noktası tahmininde üç ana bileşen vardır:

  • Risk: Belirli bir kalem için, onunla ilişkili riskler belirsiz talepler, süreç ortasındaki değişiklikler ve üçüncü bir tarafa bağımlılıktır.
  • Karmaşıklık: Bir özelliği geliştirmenin zorluk seviyesini temsil eder.
  • Alım: Özelliğin ekip üyelerine aşinalığını ve geliştirme içinde belirli görevlerin ne kadar monoton olduğunu belirler.

Üç noktanın birleştirilmesi, belirsizlik için bir yastıklama, daha iyi tahminle ilgili sorunlar ve zamanında çok fazla öğrenmeden kaçınma dahil olmak üzere sprintlerin doğru bir şekilde planlanmasını sağlar.

Agile'da Hikaye Puanlarının Tahmini

Çevik hikaye noktalarını tahmin etme adımları

Çevik hikaye noktalarını tahmin ederken geliştiricilerin, tasarımcıların, testçilerin vb. katılımı kilit faktörler olarak kabul edilir . Her ekip üyesinin işi ilerletme ve ürünü teslim etme konusunda farklı bakış açıları olduğundan, etkili işbirliği önemlidir. Örneğin, herhangi bir tasarımdaki değişiklik sadece bir tasarım ekibinin çabalarını gerektirmez, aynı zamanda KG departmanının yanı sıra geliştirmenin katılımını da gerektirir.

Çevikte hikaye noktalarının tahmini ile başlamak için, ekibin mutlaka küçük olması gerekmeyen ancak ekip içinde iyi yankılanabilecek bir temel hikayeye sahip olması gerekir. Bunu, temel hikayeye dayalı olarak hikayelerin boyutlandırılmasıyla takip edilir. Referans hikayeler yardımıyla hikayeye puan verilmelidir. Her hikayeye bir puan değeri atanır.

Boyutlandırmanın Faydaları

Çevik teslimat ekibi, tahmin edilmesi daha kolay olan boyutlandırma sürecini gerçekleştirir. boyutlandırma yoluyla

  • Çalışma kapsamına genel bakış görüntülenebilir.
  • İşin boyutu birden fazla bakış açısıyla belirlenebilir.
  • Herhangi bir yanlış varsayım düzeltilebilir.
  • Kesin olamayacak şeyler temizlendi.

Boyutlandırma aşağıdakiler dikkate alınarak yapılır:

  • Yapılacak iş miktarı
  • İşin karmaşıklığı
  • İşi yaparken risk veya belirsizlik
  • Zaman aralığı

Sprintler, listelenen süreç izlenerek daha doğru bir şekilde planlanabilir:

Hikaye noktalarını tahmin etmek için üç aşamalı bir süreç :

  1. Fibonacci dizilerinin kullanımı.
  • Geleneksel insan günü değerlendirmesi, hikaye noktalarını Fibonacci sayıları aracılığıyla tahmin etmek için değiştirildi , yani 1, 2, 3, 5, 8, …
  • Bir tahmin tanımlamak için yeterince farklılaştırılmamış maddeler sunduğu için doğrusal bir ölçek kullanılmaz. Ancak, Fibonacci serisi bir problemdeki küçük sıçramaları tahmin edebilir.
  • Fibonacci serisi, dizideki bir sonraki sayının önceki iki sayının toplamı olduğu bir sayı dizisini temsil eder. Agile'da hikaye noktalarını tahmin etmek için Fibonacci dizisi 0,5, 1, 2, 3, 5, 8, 13, … olarak değiştirilir.
  1. Bir matrisin belirlenmesi
  • Her hikaye noktası için bir temel belirlenir.
  • Taban çizgisi, matrise 1 değeri olarak dahil edilir. Bu, en az miktarda risk, tekrar vb. için standart olarak belirlenir.
  1. Poker planlama

Planlama pokeri aracılığıyla ekip, her bir öğe için doğru hikaye noktası yaklaşımını kabul eder.

Poker planlamanın işleyişi

  • Sprint planlaması sırasında, her geliştirici ve testçi tarafından bir dizi kart alınır. Kartlar bir Fibonacci seri numarasını gösteriyor.
  • Öğelerin özelliklerini sorgulamak ve netleştirmek için biriktirme tablosundan bir öğe seçilir.
  • Tartışmanın sonunda, öğenin tahminini yansıtan bir kart, test eden ve geliştirici tarafından özel olarak seçilir.
  • Kartlar daha sonra tahminciler tarafından ortaya çıkar. Bir fikir birliğine varılırsa net öğeye geçerler. Değişen kartlar için, bir fikir birliğine varana kadar tartışma liderler tarafından sürdürülür.

Tamamlanmış bir matris, tahmin edicilerin planlama pokeri sırasında referans olarak kullanmaları için yararlıdır. Bu, görevler arasında daha fazla tutarlılık sağlar. Ayrıca, tahminin maksimum sınırı 13'tür, 13'ten büyükse, görevin daha küçük parçalara bölünmesi etkilidir. Ayrıca, görevin 1'den küçük olduğu tahmin ediliyorsa, başka bir göreve dahil edilmesi tavsiye edilir.

Agile'da hikaye noktalarının başarılı bir şekilde tahmin edilmesi için başka bir 8 adımlı tahmin:

  1. Temel hikayeleri belirleme
  • Çevikte hikaye noktalarını tahmin etmenin önemli adımlarından biri , biriktirme listesinin göreceli boyutlandırılması için referans olarak kullanılan bir temel hikaye belirlemektir.
  • Temel hikaye, geliştirme ekibi tarafından yürütülen önceki bir hikayeden veya mevcut bir ürün birikiminden seçilir.
  • Temel hikayenin anlaşılması, her ekip üyesi arasında aynı olmalıdır. Başka bir deyişle, temel hikaye üzerinde ekibe güven olmalıdır.
  1. Gereksinimleri tartışın
  • Hikayenin detayları tartışılmalı ve kullanıcı hikayesi ile ilgili açıklamalar Ürün Sahibi veya bir iş analisti tarafından sağlanmalıdır.
  1. Önemli şeyleri not edin
  • Önemli olması gereken tüm önemli şeyler not edilmelidir.
  • Scrum ustası bu işi en iyi devam eden tartışmalar sırasında yapar.
  1. Sorulması gereken önemli sorular

Geliştirme ekibinin kendilerine sorması gereken birkaç soru çok önemlidir.

  • Tasarıma başlamadan önce ekip üyelerinin neleri öğrenmesi gerekiyor?
  • Hikaye için kodun gerekliliği nedir? Ne kadar uzunluk gerekli ve geliştirme ekibi tarafından daha önce yazılmış benzer kodlar var mı?
  • Müşteriler tarafından kabul edilmek için ne kadar iş gerekiyor?
  • Hikayenin sahip olduğu herhangi bir dış bağımlılık var mı?
  • Ekipteki herhangi birinin aynı hikayede çalışan herhangi bir uzmanlığı veya deneyimi var mı?
  • Hikayenin, iş mantığı veya teknik perspektiflerden herhangi bir basitliği veya bununla ilişkili karmaşıklığı var mı?
  • Bağımlılıkları zamanında almak için ne kadar kesinlik var?
  1. Göreceli karşılaştırma noktaları
  • Karşılaştırma için göreceli noktalar hikayeye atanmalıdır.
  • Önceden boyutlandırılmış hikayelerle aynı miktarda çalışmaya sahip hikayeler için hikayeye aynı sayıda puan, yani 1 atanmalıdır.
  • Daha zor hikayeler için orantılı olarak daha yüksek bir değer atanmalıdır.
  • Hikaye, önceki hikayeden elde edilen öğrenme nedeniyle daha az karmaşıksa ancak bu hikayeye neredeyse benzerse, daha düşük bir değer atanacaktır.
  1. Hikayenin boyutuna göre tüm ekip arasında bir fikir birliği sağlanmalıdır.
  2. Hikayeler arasında bir iç tutarlılık olduğu gerçeğinin bir doğrulaması olmalıdır.
  3. Tekrar eden aralıklarla tüm 1'lerin aynı olması veya tüm 2'lerin eşleşmesi vs. sağlanmalıdır.

Çevik Öykü Puanı Tahmininin Faydaları

Agile'da hikaye noktalarına tahmin uygulamak , hem geliştiricilere hem de ürün sahiplerine fayda sağlar.

Geliştiricilere sunulan avantajlar şunlardır:

  • Tahmin uygulaması, geliştiricilerin bir sprint için ne kadar planlama gerektiğini bilmelerini sağlar ve dolayısıyla işi sürdürülebilir bir hızda ilerletebilir.
  • Sprintin fazla planlanmasından kaçınılır.
  • Bir üründe ihtiyaç duyulan uygulama stratejisi ve gereksinimleri, tartışmalar ve ayrıntılar yoluyla iyi anlaşılır.

Ürün sahiplerine sunulan avantajlar şunlardır:

  • Ürünün daha uzun vadeli teslimatına odaklanılabilir.
  • Öğelerin “paranın karşılığı” veya “yatırım getirisi” değerlendirilebilir.
  • Büyük parçaların teknik riskleri ürün sahipleri tarafından görülebilir.

Dünyanın En İyi Üniversitelerinden Online Yazılım Kursları Öğrenin . Kariyerinizi hızlandırmak için Yönetici PG Programları, Gelişmiş Sertifika Programları veya Yüksek Lisans Programları kazanın.

Özet

Çevik metodolojinin uygulamayı içermesi gibi, tahminin kendisi de zamanla daha iyi hale gelecek bir uygulamadır. Çevik noktaları tahmin etmenin uygulanması, sonuçta etkili bir çözümle sonuçlanan hem geliştiricilere hem de mal sahibine fayda sağlar.

Yazılım geliştirmede ustalaşmak istiyorsanız, öne çıkın ve upGrad tarafından sunulan Yazılım Geliştirmede Yönetici PG Programı - Tam Yığın Geliştirmede Uzmanlaşma kursunu kontrol edin.

Uzmanlık kursu, herhangi bir giriş seviyesi profesyonelin gizli yaratıcılığını yazılım geliştirmenin geleceğine dönüştürmede yardımcı olacaktır. Herhangi bir yardıma ihtiyacınız olursa, yardım ekibimizle iletişime geçebilirsiniz.

Agile'da Hikaye Puanları nedir?

Doğru hikaye noktalarını nasıl tahmin edersiniz?

Hikaye altı ay içinde gerçekleşecek bir ticaret fuarıyla ilgiliyse, o zaman iki nokta koyabilirsiniz, çünkü gereklilik değişmeyecektir. Bir kullanıcı arayüzü geliştiriyorsanız, hikaye noktaları bir olabilir. Bir sunucu programlıyorsanız, iki saat boyunca bir nokta koyabilirsiniz. Bazen ekip bir gereksinimi tahmin edemez, bu nedenle ne kadar çaba gerektireceğini bilmediğinizi belirtmek için çok sayıda puan koymak daha iyidir. Öte yandan, bir forma yeni bir düğme eklediğiniz basit bir hikayeniz varsa, bu noktanın bir olduğunu söyleyebilirsiniz. Hikaye noktalarında süreyi hesaplamak için bazı araçlar mevcuttur.

Çevik geliştirme nedir?

Çevik geliştirme, yazılım geliştirme için bir metodolojidir. Çevik geliştirmede, gereksinimler ve çözümler, kendi kendini organize eden işlevler arası ekipler arasında sürekli iletişim, geri bildirim ve işbirliği yoluyla gelişir. Scrum ve Extreme Programming (XP) gibi çeşitli yinelemeli ve artımlı metodolojiler için genel bir terimdir. İyi olup olmadığını görmek için projenin bitmesini beklemek yerine, proje boyunca düzenli aralıklarla çalışan yazılımları teslim etmek için çevik geliştirme metodolojisi oluşturuldu. Bu, belirli hedeflere sahip küçük ekipler kurarak ve her yinelemenin sonunda eksiksiz ve çalışan bir yazılım teslim ederek yapılır.