agile estimation techniques
Çevik Bir Projede Doğru Tahminler: Çevik Tahmin Üzerine Örneklerle Tam Bir İçgörü
Farklı Seviyelerde Çevik Tahmin yapmak çok önemlidir. Bu, istenen ürünün uygulanması, test edilmesi ve Müşterilere belirlenen süreler içinde zamanında teslim edilmesi için kullanacağımız toplam çabanın doğru planlanması, yönetimi ve tahmin edilmesi için yapılır.
Çevik Projede Tahmin eksikliği nedeniyle, istenmeyen ürünün teslim edilmesiyle sonuçlanabilecek ve dolayısıyla müşteriyi tatminsiz bırakabilecek uygun bir planlama ve yönetim olmayabilir.
Hikaye noktası Tahminleri, Planlama Poker, Bucket System, Affinity Mapping vb. Gibi farklı teknikler kullanılarak Agile projelerinde yapılır. Bu amaçla Agile Proje Planı Şablonu, Sürüm Planı Şablonu, Sprint Plan Şablonu, Yol Haritası Şablonu gibi farklı seviyelerde farklı tahmin şablonları kullanılır. , Kullanıcı Hikayesi Şablonu vb.
Ne öğreneceksin:
- Giriş
- Agile'de Hikaye Puanı Tahminleri
- Önerilen Araç
- Farklı Çevik Tahmin Teknikleri
- Agile'de Bütçe Hesaplama
- Çevik Geliştirme Projesinde Tahmin Şablonları
- Agile Projesinde Tahmin Aşamaları
- Sonuç
- Önerilen Kaynaklar
Giriş
Aşağıda, Çevik Tahminin 3 ana seviyesi verilmiştir.
# 1) Proje veya Teklif seviyesi Proje geliştirmenin ilk aşamalarında Hızlı Fonksiyon Noktası Analizini kullanandır.
# 2) Yayın Seviyesi öncelik temelinde kullanıcı hikayelerinin sırasını tanımlamaya yardımcı olabilecek ve ayrıca mevcut sürümde hangi hikayelerin alınabileceğine ve hangilerinin daha sonra alınabileceğine karar vermede yardımcı olabilecek kullanıcı hikayelerine hikaye noktalarının atanmasını içerir.
# 3) Sprint Seviyesi kullanıcı hikayelerinin görevlere ayrıldığı ve tahmini saatlerin karmaşıklıklarına göre görevlere atandığı yerdir. Burada görevlerin durumu ile birlikte görevden sorumlu kişiyi de tanımlıyoruz.
Bu bilgi daha sonra Agile projesinin bütçesini hesaplamak için kullanılabilir. Bütçenin hesaplanması, projenin öncesi ve sonrası iterasyon görevleri veya diğer bazı nedenlerle bütçeyi aşmadığından emin olmak için çok önemlidir.
Agile'de Hikaye Puanı Tahminleri
Hikaye Puanı tahminleri, göreli boyutlandırma ile ürün biriktirme listesi öğelerini kabaca tahmin etmeye yönelik karşılaştırmalı bir analizdir. Kullanıcı hikayelerini tahmin eden ekip üyeleri şunları içerir: Ürün Sahibi, Scrum Master, Geliştiriciler, Test Edenler ve Paydaşlar.
Aşağıda, göreceli boyutlandırmanın nihai kararına ulaşmak için birkaç adım verilmiştir:
# 1) Tüm kullanıcı hikayelerini analiz edin ve temel veya referans hikayeyi belirleyin. Göreceli boyutlandırma yapmak için önemlidir. Bu hikaye, mevcut ürün birikiminden veya daha önce yaptığımızdan seçilebilir. Bu hikaye, tüm üyelerin mutabakatı üzerine referans hikaye olarak seçilmelidir.
#iki) Mevcut Ürün İstek Listesinden başka bir hikaye seçin ve ekip üyeleri hikayenin gerekliliklerini anlarken Ürün Sahibi ile soru veya şüphelerini tartışmakta özgürdür. Ürün Sahibi, tüm soru ve şüphelerini netleştirmekle sorumludur.
# 3) Kullanıcı hikayesini uygularken dikkat edilmesi gereken şeylerin bir listesini yapın. Bunlar, aracın notlar bölümüne notlar yazarak veya hikaye kartına madde işaretleri ekleyerek yapılabilir. Bu çoğunlukla Scrum Master tarafından yapılır.
# 4) Aşağıda, katılımcılar arasında sıkça sorulan birkaç soru yer almaktadır:
- Tasarım: Üzerinde çalışmaya başlamadan önce sahip olmamız gereken önceki ve zorunlu bilgi nedir?
- Kodlama: Bu kullanıcı hikayesini uygulamak için ne kadar kodlama gerekli. Daha önce benzer bir kullanıcı hikayesine rastladık mı?
- Birim Testi: Bu kullanıcı hikayesinde birim testi yapmak için herhangi bir sahte nesne gerekli mi?
- Entegrasyon Testi: Bu hikaye aynı modülün diğer işlevlerini ve diğer modülleri de etkiliyor mu?
- Kabul testleri: İstenilen ürünü Müşterinin istediği şekilde teslim etmek için dikkat edilmesi gereken noktalar nelerdir?
- Uzmanlık: Katılımcılardan herhangi biri daha önce benzer bir hikaye yapmış mı ve bu konuda uzman mı?
# 5) Seçilen hikaye için göreceli boyutlandırma yapın. Aynı miktarda çalışma ve çaba gerektiriyorsa, aynı numarayı atayın. referans hikayeye atanan puan sayısı. Daha fazla çaba gerektiriyorsa, ona daha yüksek bir değer atayın. Daha az çaba gerektiriyorsa, biraz daha düşük bir değer atayın.
# 6) Bitti tanımına göre seçilen kullanıcı hikayesinin göreceli boyutunu sonlandırmak için tüm katılımcılarla bir fikir birliğine varın.
selenyum css seçici tarafından eleman bul
# 7) Tüm ürün birikimi öğelerinin göreceli olarak boyutlandırılmasından sonra, tüm kullanıcı öykülerinin aynı no. onlara verilen puanların tutarlı olması için aynı çaba ve boyut gerekir.
Önerilen Araç
# 1) Çevik Poker
Çevik Poker hem uzak hem de aynı konumdaki ekipler için hızlı ve kolay planlama ve tahminler için Jira için iyi bilinen bir uygulamadır.
Çevik Poker'e başlamak, endüstri standardı olan üç tahmin metodolojisinden esinlendiği için basit ve kolaydır: Planning Poker®, Wideband Delphi ve Magic Estimation (aynı zamanda Sessiz Gruplandırma, Affinity Estimation, Swimlanes Sizeing veya Relative Estimations olarak da bilinir).
=> Çevik Poker Aracını Buradan İndirinFarklı Çevik Tahmin Teknikleri
Bir Agile Projesinde tahmin yapmak için birçok teknik vardır. Tahmin yapmanın ana ilkeleri arasında Göreceli Tahmin, tahminlerinin yapılması gereken öğeler hakkında daha fazla bilgi almak için tartışmalar ve tüm ekibin kendilerine verilen görevlere bağlılığının sağlanması yer alır.
Başlıca 7 Çevik Proje Tahmin Tekniği vardır:
# 1) Planlama Poker
- Bu Tahmin tekniğinde, tahminleri yapması gereken tüm insanlar Planning Poker oturumu için yuvarlak bir daire şeklinde otururlar.
- Her tahmin edicinin bir dizi Planlama Poker Kartı vardır: 0,1,2,3,5,8,13,20,40 ve 100. Bu değerler, takımın tahmin ettiği hikaye noktalarını veya ölçüyü temsil eder.
- Oturumun başlangıcında, ürün sahibi veya müşteri, tüm özelliklerini ve gereksinimlerini açıklayarak kullanıcı hikayesini okur.
- Hikaye okunduktan sonra tahmin ediciler arasında ve ürün sahibi / müşteri ile görüşmeler gerçekleşir. Tahminciler, ürün sahibine sorular sorabilir veya şüphelerini netleştirebilir.
- Tartışmalardan sonra, tüm tahmincilerden bir kullanıcı hikayesini tahmin etmek için bir kart seçmeleri istenir. Tüm tahmin ediciler aynı değeri verirse, bu nihai tahmin olur.
- Değerler farklıysa, en yüksek ve en düşük değerleri veren tahmin ediciler fikirlerini ve bir fikir birliğine varılıncaya kadar neden bu değeri seçtiklerini açıklar.
- Küçükken iyi bir teknik hayır. küçük bir ekipte ürün sayısı tahmin edilecek.
=> Daha ayrıntılı okuma Poker Tahmin Tekniğini Planlama .
# 2) T-Shirt Ölçüleri
- Tişörtlerde olduğu gibi bedenleri görüyoruz: XS (Ekstra Küçük), S (Küçük), M (Orta), L (Büyük), XL (Ekstra Büyük). Burada da benzer bir yaklaşım izleniyor, ürünler tişört bedenlerinde tahmin ediliyor.
- Bu, kalemlerin büyük birikimi hakkında kabaca bir tahmin vermek için mükemmel bir tekniktir.
- Hızlı ve kaba tahminin yapılması gerektiğinde kullanışlıdır. Daha sonra bu boyutlar ihtiyaca göre no'lara dönüştürülebilir.
- Ekip üyelerinin veya tahmin edicilerin karşılıklı görüşmesi ve mutabakatından sonra göreceli bir boyuta (çoğunlukla Orta) karar verilir. Daha sonra, no'lar, Medium size atanan göreceli boyuta göre maddelere atanır.
- Dezavantaj: Birine L gibi görünen şey, biri için XL gibi görünebilir.
- Tüm tahmin ediciler, öğelere kendi boyutlarını atar. Tartışmalardan ve uyumsuzlukları çözdükten sonra, nihai tahmini almak için bir fikir birliğine varılır.
# 3) Nokta Oylama
- Bu, temelde Ürün İş Listesinin en yüksek öncelikli öykülerden en düşük öncelikli öykülere doğru sırasına karar vermek için bir sıralama yöntemidir. Bu, ileriye götürülmesi gereken en önemli hikayeleri seçmek için yapılır.
- Bununla başlamak için, tüm kullanıcı hikayelerini açıklamalarıyla birlikte sarı yapışkanlar kullanarak veya oyları almak için onları ayırt edecek şekilde duvara veya tahtaya yayınlayın.
- Tüm paydaşlara 4 ila 5 nokta verilmiştir (çoğunlukla etiket, kalem veya işaretçi şeklinde nokta yapmak için de kullanılabilir).
- Tüm paydaşlardan tercih ettikleri kullanıcı hikayelerine oy vermeleri istenir.
- Ürün Sahibi, ürün biriktirme kalemlerini en çok tercih edilenlerden (en fazla nokta içermeyen) en az tercih edilene (en az nokta içermeyen) doğru sıralar.
- Birkaç paydaşın kararlaştırılan siparişten memnun olmadığı durum söz konusu olabilir. Bu durumda, kullanıcı hikayeleri tartışmalardan sonra 3 gruba ayrılır: yüksek öncelikli, düşük öncelikli ve orta öncelikli. Oyları almak için yüksek öncelikli kullanıcı hikayeleri duvara asılır. Bu, tüm paydaşların mutabakatı ile nihai siparişe ulaşılıncaya kadar yapılır.
# 4) Kova Sistemi
- Büyük bir hayır olduğunda iyi bir tekniktir. ürün sayısı büyük no ile tahmin edilecektir. katılımcıların. Planning Poker'den daha hızlı ve daha makul.
- 0,1,2,3,4,5,8,13,20,30,50,100, 200 değerleriyle farklı kovalar oluşturulur. Bu, gerekirse uzatılabilir. Bu kovalar, bir masada sıralı olarak düzenlenmiş değerleri temsil eden kartlardan başka bir şey değildir.
- Hikayelerin, tahmin edicinin onları uygun bulduğu yerlere yerleştirilmesi gerekir. Tahmin edilecek tüm kalemler kartların üzerine yazılır.
- Rastgele bir ürün seçin ve 8 numaralı kovaya koyun. Bu sadece referans için kullanılır. Rastgele başka bir hikaye seçin, tüm özelliklerini ve gereksinimlerini grupla tartışın ve fikir birliği üzerine uygun kovaya koyun. Benzer şekilde üçüncü öğe alınır ve uygun bir kovaya yerleştirilir.
- Grup dizisi, grubun seçilen ilk öğeyi kova 8 yerine kova 1'e ait olduğunu düşünmesi durumunda da değiştirilebilir.
- Böl ve Fethet yaklaşımı izlenir. Kalan tüm öğeler tüm katılımcılar arasında bölünmüştür. Tüm katılımcılar diğer katılımcıların onayı olmadan öğeyi yerleştirebilir.
- Öğeler uygun şekilde yerleştirilmelidir. Kovalar arasına hiçbir öğe yerleştirilemez.
- Bir katılımcı ürün biriktirme listesini anlamazsa veya diğer katılımcılar kullanıcı hikayelerini yerleştirmeyi tamamladıysa, kullanıcı hikayeleri diğer katılımcılara aktarılabilir.
- Sonunda tüm katılımcılar tarafından Sağlık kontrolü yapılır. Herhangi bir katılımcı bir öğeye atanmış yanlış bir kova bulursa, bunu diğer katılımcıların dikkatine getirebilir ve onlarla tartışabilir. Bu, tüm ürün birikimi için bir fikir birliği sağlanıncaya kadar yapılır.
- Kolaylaştırıcı, akıl sağlığı kontrolü yapılmadıkça kimsenin öğeleri hareket ettirmediğinden emin olmalıdır.
- Bu aynı zamanda, ürün biriktirme kalemlerinin öncelik sırasına ulaşmak için de yapılır.
# 5) Büyük / Belirsiz / Küçük
- Bu kaba bir versiyondur ve yalnızca üç boyutun olduğu kova sisteminin basitleştirilmesidir: Büyük, Küçük ve Belirsiz.
- Katılımcılardan veya tahmin edicilerden maddeleri kategorilerden birine yerleştirmeleri istenir. İlk olarak, basit kullanıcı hikayeleri seçilir ve büyük ve küçük kategorilere yerleştirilir. Ardından karmaşık öğeler ele alınır.
- Ürün İstek Listesinde karşılaştırılabilir öğeler olduğunda bu iyi bir tekniktir.
# 6) Yakın İlgi Alanı Eşleme
- Takım küçük ve hayır olduğunda iyi bir teknik. birikmiş öğe sayısı daha az.
- İlk adım Sessiz Bağıl Boyutlandırmadır: Bir duvarda, en sol tarafa üzerinde 'Küçük' yazan bir kart, en sağdaki ise üzerinde 'Büyük' yazan kart yerleştirilir. Ürün Sahibi, tüm katılımcılara öğelerin bir alt kümesini sağlar. Tüm katılımcılardan, her bir öğeyi, onları uygulamak için gereken çabayı göz önünde bulundurarak, duvardaki kartlardaki boyutlara göre boyutlandırmaları istenir. Katılımcının diğer ekip üyeleriyle tartışmadan tek başına aldığı karardır. Ürün Sahibi veya paydaş katılımcının şüphelerini netleştirmek için hazır bulunur. Ekip üyeleri tarafından tahmin edilemeyecek kadar belirsiz olan Ürün İş Listesi maddeleri ayrı ayrı yerleştirilir. 5-20 dakika sürer.
- Duvarın düzenlenmesi: Ekip üyeleri, duvardaki öğelerin yerini değiştirebilir. Diğer ekip üyeleriyle tasarım ve uygulama gereksinimlerini tartışabilirler. Duvarda küçük bir değişiklik olduğunda bu aktivite kapatılabilir. Yaklaşık 20-60 dakika sürer .
- Öğeleri doğru yerlere yerleştirmek: Tartışmalardan sonra ekip, ürün biriktirme kalemlerini göreceli ve uygun konumlarına yerleştirir. Burada, öğelerin boyutunu nispeten tahmin etmek için T-shirt boyutlandırma, Fibonacci serileri vb. Kullanabiliriz.
- Ürün Sahibi Meydan Okuması: Ürün Sahibi, ekip tarafından yapılan tahminlerde bir miktar tutarsızlık bulabilir ve daha fazla özelliği veya bir öğenin gereksinimlerini ekiple tartışması gerekebilir. Tartışmalardan sonra nihai tahminler yapılır.
- Proje İş Listesi Yönetim Aracına Aktarma: Nihai tahminler hakkındaki bilgilerin kaybolmadığından emin olmak için, bu bilgileri bir ürün birikimi yönetim aracına aktarın.
# 7) Sipariş Yöntemi
- Hayır büyük olduğunda iyi bir teknik. ürün ve küçük no. orada insan var.
- Ürün biriktirme listesi öğeleri için doğru göreceli boyutlar verir.
- Düşükten yükseğe doğru değişen bir ölçek hazırlanır. Tüm eşyalar üzerine rastgele yerleştirilir. Her katılımcıdan bir defada ölçekte herhangi bir maddeyi hareket ettirmesi istenir. Hareket bir yukarı, bir aşağı olabilir veya dönüşü başka bir üyeye geçirebilir.
- Bu, tüm katılımcılar tatmin oluncaya ve ölçekte herhangi bir öğeyi taşımak istemeyene kadar devam eder.
- Bu aynı zamanda Ürün İş Listesi maddelerinin öncelik sırasını da verir.
Agile'de Bütçe Hesaplama
Bütçelerin Hesaplanması, Çevik projelerde önemli bir rol oynar. Bu, sağlanan gerçek bütçenin ne olduğundan, daha fazla bütçe gerektiğinden ve farklı ürün biriktirme listesi kalemleri için bütçeyi nasıl böleceğimizden emin olmak için yapılır.
Önceki projelerden toplanan verileri kullanır ve mevcut proje için tahmini bütçeyi elde etmek için matematiksel formülü kullanır.
Aşağıda, bir Agile projesinde bütçeyi hesaplamak için gereken adımların sırası verilmiştir:
# 1) Projenin tüm gereksinimlerini listeleyin ve tahminler Planlama Poker, Bucket System, Fibonacci serileri vb. kullananlar için. Tüm ekip üyeleri, kullanıcı hikayelerini net bir şekilde analiz edip anladıktan sonra listelenen gereksinimler için yapılan tahminler üzerinde anlaşmalıdır. Tahminler, bir kullanıcı hikayesinde uygulanacak özelliklere göre yapılır.
#iki) Sprint adı verilen yinelemelerin ve ona atanan ürün biriktirme listesi öğelerinin süresini belirleyin. Genellikle 2 ila 3 hafta uzunluğundadır. Kullanıcı hikayeleri, maksimum önceliğe sahip kullanıcı hikayesinden başlayarak, daha düşük önceliğe geçerek ve sonunda en az öncelikli kullanıcı hikayesiyle başlayarak sırayla seçilir. Bu, ilk Sprint'te hangi kullanıcı hikayelerinin alınması gerektiğine ve hangi hikayelerin daha sonra ele alınabileceğine karar vermede yardımcı olur.
# 3) Ne kadar iş yapılması gerektiğine karşı uygulama için ne kadar zaman kaldığına dair net bir resim vermek için yanmış çizelge hazırlayın. Temel olarak bir Agile ekibinin ilerleme hızını verir. Takımın nasıl davrandığına ve nasıl davranmasının beklendiğine dair net bir resim verir.
Ekip ilerlemesi, aşağıda gösterildiği gibi Tamamlanan görevler, Kalan Çaba, İdeal kapanma ve Kalan Görevler açısından ölçülür:
# 4) Ekipman satın alımı, araçlar, altyapı desteği, kullanılacak yazılım araçları için lisans alma, Proje Yönetimi Araçları, Antivirüs kurulumu ve güncellemeler gibi Ek Maliyetler ekleyin.
# 5) Yineleme Öncesi ve Sonrası Bütçeleri Ekleyin. Tüm çevik üyelerin çapraz işlevli olması gerekir, ancak bunun sınırları vardır. Bir ekip üyesinin uzmanlığı dışında yaptığı her şey, ön yineleme çalışması veya yineleme sonrası çalışma olarak kabul edilir. Bu Pre ve Post Yineleme çalışmaları, uygulama için ek bütçe gerektirir.
# 6) Gizli risklere göz kulak olmak. Agile projesindeki riskler şunları içerir: Projenin bütçeyi aşma riski, Ekip üyelerinin yokluğu, Üyelerin açık veya tam bilgisi yok, Üyelerin gerekli becerilere sahip olmaması, son teslim tarihlerinin geçilmesi vb.
Çevik Geliştirme Projesinde Tahmin Şablonları
Agile geliştirme projesinde farklı seviyelerde hazırlanan birçok tahmin şablonu bulunmaktadır. Tek amaç, bir gereksinimi veya maddeyi uygulamak ve ilerlemesini izlemek için gerekli tahminleri açıkça belirtmektir.
Ana şablonlar aşağıda belirtildiği gibidir:
1) Çevik Proje Planı Şablonu:
Gereksinimlerin özelliklerini sunmak için ne kadar zaman gerektiğine ve durumlarının ne olduğuna dair üst düzey bir görünüm sağlar. Aynı zamanda belirli bir görevden sorumlu kişiden de bahseder.
(Not: Büyütülmüş bir görünüm için herhangi bir resme tıklayın)
2) Çevik Yayın Planı Şablonu:
Gereksinimlere karşılık gelen görevlerin sürüm ayrıntılarını, bunların durumları ve gerçekleştirilmesi gereken Sprint ile birlikte verir.
3) Çevik Ürün İş Listesi Şablonu:
Proje için tanımlanan eksiksiz ürün birikimini açıklar. Durum, öncelik, hikaye noktaları ve bunların bir Sprint'e atanıp atanmadığı veya kusurlar vb. Gibi bazı ek görevler olup olmadığı ile birlikte Sprintlerin görevlerinin ayrıntılarını verir.
4) Çevik Sprint İş Listesi Şablonu:
Belirli bir Sprint'in iş yığınında bahsedilen kullanıcı hikayelerinin bir tanımını verir. Bir kullanıcı hikayesine atanan toplam hikaye puanlarını ve bunların farklı görevlere nasıl bölündüğünü verir. Aynı zamanda ilgili görevlerin durumunu ve karşılık gelen görevler için günlük olarak yürütülen işin ne olduğunu da verir.
5) Çevik Test Planı Şablonu:
Tüm test senaryosunu alt senaryolara böler. Uygulama tarihi, Beklenen Sonuç, Gerçek Sonuç, Durum gibi alt senaryoların detaylarını verir.
Ayrıca Proje Adı, Uyumlu tarayıcı, Test edilen Uygulamanın Sürümü, seçilen bir senaryo için Test Durumu Kimliği, Yazan, Test Eden, Açıklama vb.
6) Çevik Kullanıcı Hikayesi Şablonu:
Test edilecek belirli bir işlevsellik için gereken roller nelerdir, ön gereksinim nedir (ortam kurulumu ve bağlantılar etkin) ve beklenen sonuç nedir gibi kullanıcı öyküsünün analizine özgü ayrıntıları verir.
7) Çevik Yol Haritası Şablonu:
Şirket içerisinde kısa ve uzun vadede projeye yön verir. Şirket içinde beklentilerin belirlenmesine yardımcı olur. Ve projenin nereye gittiğine dair genel bakış.
Agile Projesinde Tahmin Aşamaları
Çevik bir Projede, tahminler aşağıda belirtildiği gibi 3 seviyede yapılır:
- Proje / Teklif Seviyesi: Tüm uygulamanın toplam işlevsel boyutu, yalnızca üst düzey gereksinimler mevcut olduğunda Hızlı İşlev Noktası Analizi (QFPA) yöntemi kullanılarak tahmin edilir.
- Yayın Seviyesi: Öykü puanları, numarayı belirlemede yardımcı olan kullanıcı öykülerine atanır. bir proje kapsamında planlanan yayınların sayısı ve no. bir sürümde ve sprintte alınacak kullanıcı hikayeleri.
- Sprint Seviyesi: Bir sprint içinde kullanıcı hikayelerinin görevlerine tahmini saatler atanır. Bu, bir sprintte kullanıcı hikayeleri sunmak için geliştirme taahhüdünü sağlamak için yapılır.
S1, S2, S3, S4, S5, S6 sprintlerdir.
# 1) Teklif veya Proje Seviyesi Tahmini
Proje için çok üst düzey bir tahmin. Ürün İstek Listesi öğesindeki toplam gereksinim sayısına odaklanır. İşlev Noktaları, işlevsel gereksinimlerin ayrıntılı bir açıklaması belgelenmeden önce yazılımın / projenin boyutunu tahmin etmek için kullanılır.
İşlev noktaları, yazılımın boyutunu hesaplamanın evrensel olarak kabul edilmiş yoludur. Yazılım projelerinde bulunan işlevlere odaklanır. İşlev noktası, gereksinimleri veya kullanıcı öykülerini sayıya dönüştüren bir metriktir.
Projenin ilk aşamalarında Hızlı Fonksiyon Noktası Analizi (QFPA) yönteminin benimsenmesi önerilmektedir.
Hızlı Fonksiyon Noktası Analizi yöntemi, yalnızca üst düzey gereksinimler mevcut olduğunda FP'yi tahmin etmek için benzersiz bir yaklaşımdır.
Toplam İşlevsel boyut nasıl hesaplanır?
- Alan uzmanlarının yardımıyla bir uygulamanın tüm işlevlerini anlayın.
- Bir uygulamanın tüm olası işlevlerini belirleyin ve listeleyin.
- Veri depolama işlevleri, Dahili Mantık Dosyaları (uygulama içinde dahili olarak depolanan veriler) ve Harici Arayüz Dosyaları (yalnızca referans amacıyla kullanılan veriler) olarak sınıflandırılır.
- İşlem fonksiyonları, Harici Girişler (harici kaynaklardan uygulamaya gelen veriler), Harici Çıkışlar (türetilen veriler uygulamadan dışarıya gider) ve Harici Sorgular (bir veya daha fazla Harici Girişten ve Harici çıkıştan alınan veriler) olarak sınıflandırılır.
- Ortalama karmaşıklığını hesaplayarak her işlev için FP boyutunu hesaplayın.
- Uygulamanın Toplam İşlevsel Boyutunu elde etmek için tüm işlevlerin FP boyutunu toplayın.
- FP analizinde uzman en az iki kişi bağımsız olarak hesaplamalı, sonuçları eşleştirmeli ve farklılıkları çözmelidir.
Proje Düzeyinde Tahmin Örneği:
Ürün İstek Listesindeki gibi bir proje için gereksinimlerin listesi aşağıdadır:
- Bir kullanıcı, kullanıcı adı ve şifresini sağlayarak web sitesine giriş yapabilmelidir.
- Başarılı bir giriş yaptıktan sonra, bir kullanıcı sağ ve sol bölmeleri tanımlanmış ana sayfaya götürülmelidir.
- Bir kullanıcının Uygulamadan çıkış yapma seçeneği olmalıdır.
- Geçerli bir kullanıcı, geçerli kimlik bilgilerini sağlayarak parolayı değiştirme seçeneğine sahiptir.
Ekip, proje boyutunu tahmin etmek için Hızlı FP tahmini kullanır.
Yapılan analiz şu şekildedir:
- Buradaki veri depolama işlevi, oturum açmak ve parolayı değiştirmek için Kullanıcı Kimlik Bilgilerini saklıyor.
- Kimlik bilgileri uygulama sınırları içinde saklandığından, ILF'lerde (Dahili Mantıksal Dosyalar) saklanır.
- İşlem işlevleri şunları içerir:
- Kullanıcı girişi ve ana sayfanın görüntülenmesi.
- Kullanıcı oturumu kapatma ve oturum kapatma ekranının görüntülenmesi.
- Parolayı değiştirme yeteneği.
Aşağıda, Hızlı Fonksiyon Noktası Analizi kullanarak Proje boyutunu tahmin etmek için yürütülen adımlar verilmiştir:
ADIM # 1: Tüm Veri İşlevlerini listeleyin
Veri Fonksiyonu | Tür | UFP | |||||
---|---|---|---|---|---|---|---|
BİZE-02 | TAS-07 | Dahili müşteri tarafından kabul testi | Kabul testleri | Yerinde QA Ekibi | 8 | Başlatılmadı | 6 |
Kullanıcı Kimlik Bilgileri | ILF | 10 |
UFP (Ayarlanmamış Fonksiyon Noktası), Caper Jones Tablosundan alınmıştır.
ADIM # 2: Tüm İşlem İşlevlerini listeleyin
İşlem Fonksiyonu | Tür | UFP |
---|---|---|
Giriş yapın ve ana sayfayı görüntüleyin | EQ | 4 |
Oturumu kapatın ve oturum kapatma ekranını görüntüleyin | EQ | 4 |
Şifre değiştir | HAYIR | 4 |
UFP (Ayarlanmamış Fonksiyon Noktası), Caper Jones Tablosundan alınmıştır.
ADIM # 3: Fonksiyon Noktalarında tahmini proje boyutunu türetme
UFP = Veri FP + İşlem FP
UFP = 10 + 12 = 22 UFP
FP = UFP * VFP = 22 * 1 = 22 FP (Varsayım VFP (Değer Ayarlama Faktörü = 1)
Verimlilik = 16 FP / ay (Normal Standart)
Çaba = AP / Verimlilik = 22/16-kişi ay = 1.37 kişi ay
# 2) Yayın Seviyesi Tahmini
Yayın seviyesi tahminleri, Sürüm planlaması sırasında yapılır. Proje seviyesi tahmininden sonraki faaliyettir. Öncelikli gereksinimler, Kullanıcı Hikayeleri şeklindeki Ürün İş Listesinden alınır.
Kullanıcı hikayeleri, o sürüm için teslim edilecek yazılımın boyutunun tahmin edilmesine odaklanan Sürüm planlaması sırasında hikaye puanları açısından tahmin edilir. Bu şekilde, her sürümde yayın sayısı ve toplam hikaye puanı planlanmaz.
Bir hikaye noktası, temel olarak, diğer özelliklerle karşılaştırıldığında bir özelliği veya işlevselliği uygulamak için gereken göreceli çabayı temsil eder. Temel olarak Ürün İstek Listesi maddelerini boyutlandırmak içindir.
Hikaye noktası tahmini şunlara göre yapılır:
- Uygulanacak özelliğin karmaşıklığı.
- Tüm üyelerin deneyimi ve teknik becerileri.
S1, S2, S3, S4, S5 sprintlerdir.
Bir kullanıcı hikayesine hikaye noktaları atamak için adımlar:
- Tüm ekip üyeleri, Sprint İş Listesinde bulunan kullanıcı hikayelerini gözden geçiren bir masa etrafında toplanır.
- Bir hikaye noktasının anlamı ve buna karşılık gelen çabaya karar verilir.
- Ekip üyelerinden biri bir kullanıcı hikayesini okur ve ardından ekip üyelerinden ilgili hikaye noktalarını atamalarını ister.
- Ekip üyeleri tarafından verilen hikaye puanları arasında önemli bir fark varsa, atadıkları hikaye puanları için bir açıklama yaparlar ve sonunda bir fikir birliğine varırlar.
- Takım üyeleri tarafından verilen tahminler arasında büyük bir fark kalmayana kadar süreç 3-4 kez tekrarlanır.
- Hikayelerin boyutlandırılması, bir sprint ve sürümde kaç hikayenin alınacağını belirlemeye yardımcı olur.
Yayın Düzeyi Tahmini için Örnek:
Bu, Ürün İstek Listesi adı verilen, öncelikli bir Kullanıcı Hikayeleri listesi oluşturmayı içerir. Ürün Sahibi, Ürün İş Listesi oluşturur ve içinde listelenen her bir öğe için iş değeri sağlar.
Kullanıcı Hikayesi Kimliği | Kullanıcı hikayesi | Kabul kriterleri |
---|---|---|
US-01 | Bir Kullanıcı olarak, kimlik bilgilerimi kullanarak uygulamaya giriş yapabileceğim bir giriş ekranına sahip olmak istiyorum: kullanıcı adı ve şifre | • Geçerli bir kullanıcı, oturum açma ekranını görebilmeli ve kimlik bilgilerini sağlayabilmelidir. • Oturum açtıktan sonra, kullanıcı kimlik bilgilerinin doğruluğu kontrol edilmelidir. |
BİZE-02 | Kullanıcı olarak başarılı bir giriş yaptıktan sonra, ana sayfayı başlık, sol, sağ bölmeler ve çıkış seçeneği ile görmek istiyorum. | • Geçerli bir kullanıcı, başarılı bir şekilde oturum açtığında Ana ekranı görebilmelidir. • Kullanıcı, çıkış seçeneği ile birlikte başlık, sol ve sağ bölmeleri görebilmelidir. |
BİZE-03 | Bir Kullanıcı olarak, oturumu kapat seçeneğini tıklatarak başarılı bir şekilde oturumu kapatabilmeliyim ve oturumu kapattıktan sonra, oturum kapatma ekranını görmeliyim. | • Ana sayfadayken, kullanıcı 'oturumu kapat' düğmesine tıklayabilmelidir. • Kullanıcı 'oturumu kapat' ı tıkladığında başarıyla çıkış yapmış olmalıdır. • Kullanıcı, oturumu kapattıktan sonra oturum kapatma ekranını görmelidir. • Kullanıcı, oturumu kapattıktan sonra tekrar oturum açabilmelidir. |
Hikaye Puanı Tahminleri için aşağıdaki yöntemleri kullanabiliriz:
- Sayısal Boyutlandırma: 1'den 10'a
- Tişört Ölçüleri: Her gereksinim Ekstra Küçük (XS), Küçük (S), Orta (M), Büyük (L), Ekstra Büyük (XL) olarak sınıflandırılır.
- Fibonacci Serisi: Fibonacci Dizisi ile yapılan tahmin (1,2,3,5,8,13,21,34,….)
Yukarıdaki kullanıcı hikayelerinin Fibonacci dizisi aracılığıyla tahmini:
ABD kimliği | Tahmini Hikaye Puanları |
---|---|
US-01 | 8 |
BİZE-02 | 3 |
BİZE-03 | 4 |
# 3) Sprint Seviye Tahmini
Sprint seviyesi tahminleri, Sprint Planlama sırasında yapılır. En yüksek öncelikli ürün birikimi öğeleri alınır ve Detaylandırma, Tasarım, Analiz, Geliştirme, Test Durumları Oluşturma, Test Durumlarını Yürütme, Kullanıcı Kabul Testi vb. Gibi farklı görevlere bölünür.
Görevler, tahmini saatler, yani ilgili bir kullanıcı hikayesi için bu görevi tamamlamak için gereken süre cinsinden tahmin edilir. Aşağıdan Yukarı Yaklaşım, iş gereksinimlerinin düşük seviyeli faaliyetlere bölündüğü ve her bir faaliyete tahmini saatlerin atandığı Görev tahminleri için kullanılır.
Tahminlerin amacı, geliştirme ekibinin bir Sprint'e kaç kullanıcı hikayesi verebileceğini bilmektir. Geliştirme taahhütle rahat olmalı ve Ürün Sahipleri, ekibin taahhüdü yerine getireceğinden emin olmalıdır.
deneyimli kişiler için manuel test mülakat soruları ve cevapları
S görevlere tahmini saatleri atamak için teps:
- Ekip üyeleri, kullanıcı hikayelerini alır ve kullanıcı hikayesine karşılık gelen görevler için saat veya gün cinsinden gerçek çabayı tahmin etmeleri istenir.
- Ekip üyeleri arasında bu tahminlerde bir anlaşmazlık varsa, bunu tartışırlar ve fikir birliğine varırlar.
- Herhangi bir görev altı saatten fazlaysa, daha küçük görevlere bölünür.
- Tahmini saatleri ikiden az olan iki veya daha fazla görev varsa, bunlar yeni bir görev oluşturmak için birleştirilir.
Sprint Seviye Tahmini Örneği:
Sprint Planlama toplantısının iki bölümü vardır:
- İlk kısım: Ürün İstek Listesinden seçilen Kullanıcı Hikayeleri için gereksinimleri netleştirmeye odaklanılır.
- İkinci kısım: Odak noktası, gereksinimleri görevlere ayırmak ve bunları tamamlamak için gereken saatleri tahmin etmektir. Ürün İstek Listesi maddesinin teslim edilebilir olması için gerekli tüm görevler dahil edilmelidir. Görevler küçük olmalıdır. İdeal olarak, bir görev çabası altı saatten fazla olmamalıdır.
ABD kimliği | Görev Kimliği | Görev tanımı | Görev Etkinliği | Atandı | Öncelik (1 = düşük - 9 = en yüksek) | Durum | Tahmini Çalışma Saatleri |
---|---|---|---|---|---|---|---|
US-01 | TAS-01 | Oturum Açma Sayfası Tasarlanıyor | Sistem tasarımı | Amit | 9 | Tamamlandı | 3 |
US-01 | TAS-02 | Ünite Test Planı ve Sistem Test Planı | Sistem Test Planı | Teklif ver | 8 | Tamamlandı | 4 |
US-01 | TAS-03 | Giriş Sayfası Geliştirin | İnşa etmek | Geliştirme Takımı | 7 | Tamamlandı | 5 |
US-01 | TAS-04 | Oturum açma sayfası kullanıcı doğrulaması | İnşa etmek | Geliştirme Takımı | 6 | Devam etmekte | 6 |
BİZE-02 | TAS-05 | Giriş sayfasının sistem testi başarı ve başarısızlık senaryoları | Sistem Testi | Offshore QA Ekibi | 5 | Başlatılmadı | 4 |
BİZE-02 | TAS-06 | Oturum açma sayfasının entegrasyon testi | Entegrasyon testi | Offshore QA Ekibi | 4 | Başlatılmadı | 3 |
Sonuç
Agile projesindeki tahminler, doğru yönlendirme, planlama ve yönetimi sağlamak için önemli bir rol oynar. Projenin ileride nasıl ele alınacağına dair adımlar sağlar.
Planlama pokeri, Kova Sistemi vb. Gibi hikaye noktalarını tahmin etme teknikleri, üzerinde değerlerin veya numaraların basılı olduğu kartları veya noktaları kullanır ve ardından bu numaraları atar. göreli boyut tahmini için kullanıcı hikayelerine.
Tek amaç, öğeleri maksimum öncelikten minimum önceliğe öncelik sırasına göre ayarlamaktır. Ürün biriktirme kalemleri için tahmin edilen göreceli boyutlar, proje için gereken bütçenin tahmin edilmesine veya hesaplanmasına yardımcı olur.
Çevik Projelerin Tahminleri hakkında harika bir fikir edinebileceğinizi umuyoruz. Aşağıdaki yorumlar bölümünde bu eğitim hakkındaki düşüncelerinizi ifade etmekten çekinmeyin.
Önerilen Kaynaklar
- Planlama Poker ile Çevik Tahmin Süreci Nasıl Kolaylaştırılır
- Agile Vs Şelalesi: Projeniz İçin En İyi Metodoloji Hangisi?
- Yazılım Test Tahmin Teknikleri (Test Eforu Tahmin Tamamlama Kılavuzu)
- VersionOne Eğitimi: Hepsi Bir Arada Çevik Proje Yönetimi Aracı Kılavuzu
- Jira Portföy Eğitimi: JIRA için Çevik Proje Portföy Yönetimi Eklentisi (İnceleme)
- 2021'de EN İYİ 10 En İyi Çevik Proje Yönetim Aracı
- Başarılı Bir Çevik Yolculuk İçin Zemin Çalışması: Doğru Yöntem, Araçlar ve Teknikler Nasıl Seçilir
- Çevik Sürece Başarılı Geçiş için Çevik Test Zihniyetini Geliştirmeye Doğru 4 Adım