Çevik Proje Yönetiminde Yazılım Maliyet Tahmini

Tanıtım

Yazılım geliştirmede yapılması en zor şeylerden biri, yeni bir yazılım ürününü teslim etmenin ne kadar süreceğini ve ne kadar süreceğini belirlemektir. Bu kadar zor mu olmalı? Cevap basit değil.

Yazılım maliyeti tahmini doğası gereği zordur ve insanlar mutlak sonuçları tahmin etmede çok kötüdür. Hiçbir iki proje aynı değildir; her biri başarmak için yola çıktıklarında benzersiz ve varlığını oluşturan sayısız parametrede benzersizdir. Çoğu zaman, yüzeyde basit gibi görünen bir problemin gerçekte uygulanması çok daha zor veya teknik olarak zordur. Ve şüphesiz projede ancak ortaya çıktıklarında tespit edilebilecek 'bilinmeyenler' olacaktır.

Ayrıca, müşteri, geliştirici veya kullanıcı olun, iki kişi aynı değildir. Kendi bilgi birikimimiz, deneyimlerimiz, değerlerimiz, beklentilerimiz, riske karşı tutumumuz ve uyum sağlama yeteneğimizle önceden yüklü olarak geliyoruz.

Kaliteli yazılım yazmak, kıdemli mühendisler için ekmek ve tereyağı gibidir; Müthiş yazılım ürünleri yaratmak, dahil olan herkes için çok daha zor bir çaba olabilir.

Ancak, yazılım söz konusu olduğunda, stratejik iş kararları vermede süreyi ve maliyeti anlamak önemlidir ve bu, ister bir startup kuruyor olun, ister yeni bir iş fırsatı gerçekleştiriyor olun, ister işletmenizin daha iyi performans göstermesini sağlıyor olun, bu doğrudur. Zamanlama, yatırım getirisi ve sağlanan fayda, işinizi yapabilir, sarsabilir veya bozabilir. Kendinize şunu soracaksınız: Paramız için ne alıyoruz? Maliyetlerimizi tahmin edebilir miyiz? İstediğimiz ürünü yaratmanın maliyeti ne olacak? Ne zaman başlatabiliriz? Yatırımımız için kaliteli bir ürün alacak mıyız? İşimizle birlikte büyüyecek mi? İş değeri sağlayacak mı?

Peki, bir projenin boyutunu, süresini ve maliyetini nasıl tahmin edersiniz? Çevik proje tahmini ve yazılım geliştirme maliyetlerini ve bunu Toptal'da nasıl yaptığımızı keşfedelim.

Geleneksel Sözleşme Fiyatlandırması ve Tahmini

Geleneksel olarak, Çevik olmayan uygulamaları kullanan yazılım projeleri, işlevselliği veya kapsamı düzeltmeye ve zaman ile maliyetin bir değişken olmasına izin vermeye çalışmıştır. Bu sorunlara neden olur:

1. Bir projenin başında düzelttiğiniz işlevselliğin gerçekten işinize veya müşterilerinize en iyi hizmet eden işlevsellik olduğunu nasıl anlarsınız? Çoğu zaman, işlevsellik veya kapsam değişecektir, bu nedenle 'kapsam kayması', bir projenin yaşam döngüsü boyunca istenen ihtiyaçların sonucunun belirlenmesi ve gerekli veya zorunlu olarak belirlenmesi hakkında bir şeyler duyuyoruz.

2. Maliyet bir değişken haline geldiğinde, elde etmeye çalıştığımız yatırım getirisi (ROI) üzerindeki kontrolümüzü kaybederiz. Artan maliyet, genellikle tanımlanamayan risklerin veya değişen gereksinimlerin bir ürünüdür; bu, aynı zaman çerçevesinde daha fazla iş yapmak veya ekip üyelerini daha uzun süre tutmak için ekip üyeleri eklememiz gerektiği anlamına gelir. İkisi de arzu edilmez

3. Zaman bir değişken olduğunda, piyasamızdaki pozisyon üzerindeki kontrolümüzü kaybederiz. Belki de önemli bir endüstri tarihini kaçırırız veya rakiplerimiz ürünlerini bizden önce çıkarır, böylece projemizin sahip olabileceği rekabet avantajını kaybederiz.

Değişken zaman ve maliyetin, genellikle olumsuz ve istenmeyen birçok başka sonucu vardır.

Elbette birçok müşteri ve kuruluş bu 'sihirli üçgenin' üç bileşenini de düzeltmeye çalışıyor. Ne yazık ki, gerçekçi bir şekilde elde etmek neredeyse imkansız. Bu ideali sarsmak için bir araya gelen çok fazla unsur vardır ve bunlar nihayetinde bir ihtiyacı karşılamayan, müşterilerine fayda sağlaması çok uzun süren veya iş değerini gerçekleştirmek için çok pahalıya mal olan ürünlerle sonuçlanır.

Yazılım Projeleri için Çevik Sözleşmeler

Maliyet, zamanın ve insanların (ekip üyelerinin) bir ürünüdür. Daha fazla zaman ekleyin ve insanları daha uzun süre çalıştırmanın maliyetini artırın. Daha fazla ekip üyesi ekleyin ve aynı iş değerini sunma maliyetini artırın. Gerçekten kaçınmak istediğimiz şeyler. Bu nedenle Çevik ilkeler, zamanı ve ekip üyelerini sabitlemeye ve kapsamın değişken bileşen olmasına izin vermeye inanır.

Hangisi kulağa daha hoş geliyor ve paydaş güvenini, sabit maliyeti mi yoksa değişken maliyeti mi artırıyor?

Elbette, bir ürünün vaatlerini ve müşterilerinin ihtiyaçlarını karşılaması önemlidir. Sonunda, kimsenin istemediği veya etkili bir şekilde kullanamayacağı bir ürününüz varsa, kesin bir zaman ve kesin miktarda para harcamak iyi değildir.

Bu nedenle Çevik sözleşmeler aşağıdakilere odaklanır:

• Sabit fiyatlı iş paketleri - Tüm proje, tam ürün sonucuna katkıda bulunan mantıksal 'mini' sürümlere bölünmüştür. Her sürüm, buna göre fiyatlandırılan bir iş paketidir. Bir iş paketi tamamlandığında, bir öncekinden öğrendiklerimize dayanarak gelecekteki iş paketleri yeniden tahmin edilir. Bu, gereksiz beklenmedik durumları önler ve bir düzeyde yeniden önceliklendirmeye ve müşteri tarafından tanımlanacak yeni/gözden geçirilmiş özelliklere izin verir.

• Erken sonlandırma - Bu, ürünün yeterli bir kısmı teslim edilmişse ve yalnızca marjinal kazançlar sağlamaya devam edecek bir proje ekibini elinde tutarak elde edilecek başka bir yatırım getirisi yoksa müşterinin projeyi erken sonlandırmaya çalışmasına olanak tanır. Bu maddeye genellikle herhangi bir zamanda izin verilir ve proje ekibi ile müşteri güçlü, güvene dayalı ve yakın işbirliğine dayalı bir çalışma ilişkisi sürdürdüğü sürece geçerlidir. Müşterinin yararı, ürünün uygulanabilir olması için gerekli tüm değerli özelliklerin teslim edilmesiyle projenin erken bitmesidir. Karşılığında, tedarikçiye kalan sözleşme değerinin yüzde 20'si ödenir ve personel tutma riskini dengeler.

• Esnek değişiklikler - Değişim, Çevik yazılım dağıtımının damarlarında güçlü bir şekilde çalışan bir temadır. Bir ürünü başarılı kılmak için ihtiyacımız olan her şeyi en başından bilmemeyi umuyoruz. Bu nedenle, doğru ürünün teslim edildiğinden emin olmak için ilgili verilere ve geri bildirimlere dayalı olarak değişimi teşvik ediyoruz. Bir yinelemenin sonunda, artık gerekli görülmeyen veya bir öncelik olarak görülmeyen eski özellikler için değişiklikler değiştirilebilir. Değişim eşit değerde olduğu sürece, başka bir maliyet yoktur. Değişiklik daha düşük değerdeyse, ek iş tanımlanabilir veya kalan biriktirme listesinden ileri alınabilir. Bu madde, proje ekibi ve müşteri proje boyunca güçlü, güvene dayalı ve yakın çalışma işbirliği ilişkisi sürdürdüğü sürece geçerlidir.

• Ek çalışma - Bir projenin ömrü boyunca, mevcut sabit fiyat sözleşmesi kapsamında elde edilemeyecek daha fazla özellik tanımlanabilir. Bu senaryo için, proje sonuna yeni fiyatlandırılmış ek iş paketleri eklenebilir veya zaman ve malzemeye dönülebilir.

• Aralıklı tahminler - Bir Çevik proje sözleşmesinde tahminlerin sıralanmasının iki yolu vardır: bir süre aralığı veya bir dizi özellik. Bir süre aralığı, belirli bir kapsam kümesi için proje veya iş paketinin 12 ila 16 hafta süreceğini tahmin etmek için izin verir. Ancak, proje ekibi üyelerini daha uzun süre tuttuğunuz için süre eklemek maliyet ekler veya bu, diğer geliştirme projelerinde çalışmak üzere serbest bırakılamayacakları anlamına gelir. Toptal'da, kapsamı değişken olarak tutarak ancak iş paketinin veya genel projenin sabit zaman çerçevesi içinde müşteriye minimum düzeyde bir değer sunmayı vaat ederek özellikleri bir dizi hikaye noktasında sıralamayı tercih ediyoruz.

Daha sonra her zaman daha fazla kapsam ekleyebileceğinizi hatırlamakta fayda var. Belki de gelir elde etmeye başladınız, kullanıcı sayısını artırdınız veya maliyetleri düşürdünüz. Her iki durumda da, halihazırda bir geri dönüş veya gelişme gösterdiyseniz ve iş değeri sağlıyorsanız, daha fazla para ve zaman istemek çok daha kolaydır.

Yazılım maliyetlerine ve fiyatlandırmaya yaklaşımımız

Toptal'da proje süresi ve maliyetleri konusunda paydaş güvenini artıran teknikleri kullanmak için müşterilerimiz ve mühendislerimizle yakın bir şekilde çalışıyoruz. İsraftan kaçınmak ve yönetilen değişimi sağlamak için uygun ve gerekli olduğunda, planlamayı başlangıçtaki yüksek seviyeden daha ayrıntılı ayrıntılara kadar sürekli olarak detaylandırmak ve uyarlamak için çalışıyoruz.

Tahmini ve sabit fiyatlı bir projenin detaylandırılmasında aşağıdaki adımlar izlenir:

1. İlk yüksek seviye kapsam

Bir projenin başlangıcında, nihai sonucu hakkında en az bilgiye sahibiz. Müşterilerimizin ve kullanıcılarımızın tam olarak hangi özelliklere ihtiyaç duyduğunu en başından bilmenin mümkün olduğunu hayal etmek aptallıktır.

Bu nedenle, bir proje başlatma belgesi ve sağlam bir vizyon ve hedeflere dayalı olarak projenin yönüne rehberlik eden bir dizi üst düzey "destansı" özellik ile başlıyoruz.

a. Vizyon ve Hedef belirleme Neyi inşa etmemiz gerekiyor? Neyi başarmanız gerekiyor ve iş hedefleriniz neler? Bu soruları anlamak, projenin ölçeğini belirlememizi sağlar. İlk fikri, konsepti veya teknolojiyi test etmek için bir prototipe mi ihtiyacınız var? Pazarınızla test edilmiş net bir teklif belirlediniz mi ve ilk Minimum Uygulanabilir Ürününüzü (MVP) oluşturmaya hazır mısınız? Yoksa mevcut işinizi veya ürününüzü bir sonraki seviyeye taşımak için mi ölçeklendiriyorsunuz?

B. Üst düzey “destansı” özellikler Çok fazla ayrıntıya girmeden, müşterinizin ihtiyaçlarını karşılamak için ürününüzün sahip olduğu özellikleri tanımlamak isteyeceksiniz. Bu, ürününüzün temellerini açıklayan yapılandırılmış bir “alışveriş listesi”dir; genellikle bunlara “Kullanıcı Hikayeleri” veya destanlar denir.

C. MoSCoW analizi MoSCoW analizi, basitçe, ürünü uygulanabilir kılmak için gerçekten neyin gerekli olduğunu ve neyin güzel olduğunu belirlemeye yardımcı olan bir tekniktir. "Zorunlu" olarak tanımlananlar, kullanıcıları ürününüzü kullanmaya ve benimsemeye teşvik edecek şeyleri karşılar. “Olmalı” olarak tanımlanan bu özellikler müşterilerinizi şaşırtacak ve memnun edecek, ancak daha sonra oluşturulabilir. "Olabilir" öğeler genellikle önemli bir iş değeri katmaz, getiriyi artırmayabilir ve öncelikleriniz arasında en düşük olanıdır. “Olmayacak” özellikleri bir gün önemli olabilir, ancak bu proje yinelemesi için kapsam dışındadır. Bununla birlikte, bunları şimdi belirlemek, gelecekte ürünün potansiyel ölçeğini ve boyutunu akılda tutmaya yardımcı olabilir.

2. Teklif

Bir projeye devam edip etmeme konusunda karar vermek için, bu kararı iyi bilgilendirilmiş verilere dayandırmak gerekir: maliyet ve süre. Kendinize sormanız gereken minimum değerler şunlardır: İstediğimiz ürünü yaratmak için ne gerekiyor? Ne zaman başlatabiliriz? Bu, iş stratejimiz ve finansmanımızla uyumlu mu?

Yukarıdaki ayrıntılarla, bir teklif sunabilecek durumdayız. Mühendislerimiz, belirli proje gereksinimleri için özenle seçilir ve en az bir teknik çözüm, bilinen kapsamı sağlayan tahmini bir süre ve projeyi tamamlamak için tahmini bir maliyet elde etmek için bir proje yöneticisiyle birlikte çalışır.

Daha önce de belirttiğimiz gibi, bir projenin başlangıcında neyin teslim edileceğini en az biliyoruz. Özellikleri ve kapsamı kasten belirsiz tutuyoruz, çünkü aksini yapmak tam olarak neyin gerekli olduğunu bildiğimizi gösterir. Bu aşamadaki bir tahmin en az doğru olacaktır ancak projeye devam etmeye değip değmeyeceği konusunda rehberlik eder.

Teklif, bir projenin süresini ve maliyetini detaylandırmada ilk araçtır. Bir teklif kabul edildiğinde, sabit fiyatlı bir teklif sunmak için ilerlenebiliriz.

3. Yayın Planlama

Tahmini detaylandırmanın bir sonraki seviyesi, belirli bir zaman çerçevesinde bir dizi özellik sunacak bir yayın planı oluşturmaktır. Bunu bir özellikler listesinden, projenin boyutundan, ekibimizin müşterinin beklentilerini karşılayan kaliteli yazılımları ne kadar hızlı geliştirebildiğinden ve belirsizlik riskini yönetme tekniklerinden çıkarıyoruz.

a. Ürün İş Listesi Ürün iş listesi, bir ürün için gereken özellikleri temsil eden, basitçe sıralanmış bir "Destanlar" veya "Kullanıcı Öyküleri" listesidir. Bu liste, daha önce tartışılan destanlar olarak hayat buluyor, ancak atanan proje ekibi, proje yöneticisi ve müşteri arasında şimdi bunları daha anlamlı öğelere ayırıyoruz. Öğelerin her biri, müşteri için iş değerinin bir bölümünü temsil eder. Bu aşamada daha fazla ayrıntıya girmiyoruz, kabul kriterlerini bilmemize gerek yok, bir düğmenin mavi mi yeşil mi olduğunu bilmemize gerek yok, sadece bazı görevlere izin veren bir düğme olduğunu bilmemiz gerekiyor. gerçekleştirilecek.

B. Tahmin Artık kullanıcı hikayeleri olarak tanımlanan özellikler listemize sahip olduğumuza göre, ekip "Planning Poker" adı verilen bir teknik kullanarak bu ayrı özellik öğelerini tahmin ediyor. Bu, uzman görüşüne ve benzer boyutlandırmaya dayalı hızlı, güvenilir sonuçlar sağlayan kullanışlı bir tekniktir. Planning Poker, boyutunu ve karmaşıklığını temsil eden her öğeye kararlaştırılan bir numara atar. Buna hikaye noktası denir. 'İdeal günler' gibi diğer Çevik tahmin teknikleri ve boyutları mevcuttur.

Bu sürecin sonu, projenin boyutunu ve özellikler arasındaki bağımlılıkları belirleyecektir. Boyut, ürün biriktirme listesindeki öğelerden tüm hikaye noktaları toplanarak belirlenir. Bu sayı 120 ise projemizin büyüklüğü 120 kat puandır.

C. Önceliklendirme Artık proje için bir birikim ve boyutumuz olduğuna göre, müşteriyle birlikte öncelik sırasına koyabilecek bir pozisyondayız. Bu, istenen sonuçları elde etmek için müşteri için en değerli olanı belirlemekle ilgilidir. Listenin en üstündeki öğe en önemli olarak kabul edilir, ikinci öğe birinciden daha az önemlidir ve listede bu şekilde devam eder. Hiçbir iki öğe diğeri kadar önemli olamaz, her öğenin önceliği diğer öğelerin her biri için göreceli önem veya değerdedir.

Önceliklendirmeye yönelik bu yaklaşım, bir yazılım projesinin planlanmasında önemli bir kilometre taşıdır. Artık müşteri için neyin önemli olduğunu ve işi hangi sırayla tamamlayacağını, bağımlılıklara özen göstererek, beklentileri karşılayan bir ürün teslim ettiğini biliyoruz.

D. Sürüm Planlaması Bugüne kadar, ürünün ne olduğuna ve ne kadar büyük olduğuna inandığımızı belirledik.

Şimdi, piyasaya sürülebilir bir ürünün teslim edilmesinin ne kadar süreceğini belirliyoruz. Tasarımcılar, mühendisler, testçiler, scrum master ve proje yöneticisi dahil olmak üzere müşteri ve ekip, neyin başarılabileceğini ve bir sürüm planı oluşturmak için işin ne kadar hızlı yapılabileceğini belirlemek için birlikte çalışır.

Yayın planı ayrıca projenin müşterinin stratejik planlarıyla nasıl uyumlu olacağına dair fikir verir.

Ve son olarak, bu plan proje ekibine yol gösteren ve geliştirme için mantıklı bir son nokta tanımlayan yol gösterici bir ışığa sahip olmasını sağlar.

Başlamadan önce, üzerinde anlaşılan "bitti" tanımını anladığımızdan emin oluruz. Bu, bir müşterinin eksiksiz olarak kabul edeceği ve aynı zamanda serbest bırakılabilir olarak kabul edilecek tüm mühendislik gereksinimlerini karşılayacağı belirli bir kriterler dizisidir.

Temel bir senaryo almak için, biriktirme listemizi boyutlandırmaktan elde ettiğimiz toplam hikaye puanlarını alır ve bunu ekiplerimizin beklenen hızlarına böleriz. (NB hızı normalde bir aralık olarak ifade edilir, ancak basitlik için burada tek bir sayı kullanacağız.) İki haftalık yinelemeler halinde çalışıyoruz, bu nedenle hızımız, mevcut olan iki haftalık bir döngüde ne kadar tamamlayabileceğimize yansıyacaktır. takımın kapasitesi. Hikaye puanımız toplam 120 ise ve yineleme başına 20 puan tamamlamayı öngörüyorsak, toplam geliştirme süresi 12 hafta veya 6 yineleme olacaktır. Buna 2 haftalık bir 0 sprint ve iki haftalık bir sürüm hazırlık sprinti ekliyoruz. Toplamda proje süremiz 16 haftadır. Daha sonra tartışacağımız planlamamıza uygun bir risk tamponu oluşturmaya yardımcı olacak kullanabileceğimiz teknikler var. Ama kısacası, arabelleği belirsizlik riskini yönetmek ve iletilmesi beklenen hikaye noktalarında minimum anlaşmaya varmak için kullanıyoruz. Sonuç, 90 ila 150 hikaye puanı aralığı olabilir, 90'ı uygulanabilir bir ürün yaratmak için kabul edilebilecek minimum değerdir.

Alternatif olarak, projenin belirli bir tarihe kadar, örneğin 10 hafta içinde tamamlanması gerekiyorsa, ekip bu süre içinde birikmiş işlerin ne kadarının tamamlanabileceğini belirleyecektir. Sprint başına 20 hikaye puanı artı Sprint 0 ve bir sürüm sprinti öngörürsek, projenin sonunda 60 puanın tamamlanmasını hedeflemiş oluruz. Yine, tamamlanmış ve yayınlanmaya hazır 45 ila 75 hikaye noktası hedefiyle sonuçlanabilecek uygun bir arabellek ekleyerek riski yönetmeye çalışacağız. 45 hikaye noktası, uygulanabilir ve değerli bir ürün sunmak için kabul edilebilir minimum ile uyumlu olacaktır. Bu, uygunsa hızı artırmak için bir ekip üyesi eklemeyi umabileceğiniz bir senaryodur.

Tabii ki, yukarıdakilerin tümü, ulaşılabilir, gerçekçi ve müşteri tarafından kabul edilebilir bir sürüm planı elde etmek için tüm taraflar arasında kaliteli iletişim ve işbirliği ile desteklenir.

4. Sabit Fiyat Sözleşmesi

Bir sürüm planı üzerinde anlaşmaya varıldığında, sabit fiyatlı bir proje sözleşmesi için bir teklif oluşturabiliriz. Daha önce de belirtildiği gibi, proje süresini ve ekibini ve kapsam değişkenini sabit tutmanız önerilir.

Sabit fiyatlı bir sözleşme için teklif, bir iş beyanı ve üzerinde anlaşmaya varılan ödeme planı ile birlikte teslim edilir.

Güven, iletişim, işbirliği ve Çevik bir yazılım projesinin ruhuna girmeye hazır olma durumu olduğu sürece, yukarıdaki adımların tümü, bir projenin zamanında teslim edileceğine dair gerçekçi bir güvenle teklif vermemizi sağlar ve bütçede. Tabii ki, bir projenin erken veya geç teslim edildiği durumlar olacaktır ve biz bu farklılıklarla azami şeffaflıkla ilgileniyoruz.

Tahmin Teknikleri

Çevik planlama ve tahmin, bir geliştirme ekibinin büyüklük, çaba, süre ve maliyet konusunda güven kazanmak için kullanabileceği bir dizi teknikle desteklenir. İşte ekiplerimizin bir yazılım projesinin boyutunu ve maliyetini tahmin etmek için kullandıklarından bazıları.

Tahmini Boyut

Projenin boyutu, kapsamının, karmaşıklığının, boyutlarının, riskinin ve büyüklüğünün gerçekten takdir edilmesidir. Bir benzetme kullanacak olursak, Eyfel Kulesi'ni mi yoksa Çin Seddi'ni mi inşa ettiğimizi anlamakla ilgili. Eyfel kulesi, dar bir kentsel ortamda inşa edilmiş uzun, ağır, karmaşık bir yapıdır. Çin Seddi, kilometrelerce engebeli araziyi kapsayan nispeten basit ama uzun ve sağlam bir yapıdır.

Her ikisi de teslim edilecek büyük projeler olsa da kapsamları, karmaşıklıkları, boyutları, büyüklükleri ve dolayısıyla boyutları farklıdır.

Beklentileri tahminlerle yönetmek önemlidir. Asla tahmin, taahhüt veya garanti değildirler. Toplam büyüklük, toplam süre ve toplam maliyeti tartışırken, riski, belirsizliği ve bilinmeyenleri azaltmak için her zaman aralıklar içinde çalışırız.

Ürününüzün özelliklerini temsil eden hikayeler, hikaye puanları veya ideal günler kullanılarak ayrı ayrı boyutlandırılır ve tahmin edilir. Bu birimlerin toplam sayısı, projenin toplam boyutunu tanımlar.

Hikaye Puanları

Öykü noktaları, bir kullanıcı öyküsünün genel boyutunu ifade eden bir ölçü birimidir. Bir hikayenin boyutu, tahmin edildiğinde, tasarım, mühendislik, test etme, kod inceleme, entegrasyon vb. tüm yönlerini içerir.

Bir hikayenin her boyutu başka bir hikayeye göredir. Örneğin, Öykü A bir nokta, Öykü B iki puan ve Öykü C üç puan olarak boyutlandırılabilir. Burada, Öykü C, Öykü A'nın en az üç katı ve B öyküsünün en az yarısı kadar büyüktür.

Ürün biriktirme listemizdeki aşağıdaki hikayeler ilişkili boyutlara sahipse:

Projenin toplam büyüklüğü 12 kat puandır.

İdeal Günler

Bu, gün cinsinden ifade edilen bir boyut ölçüsüdür. Kesintiler, çevik planlama faaliyetleri, e-posta okuma ve diğer proje dışı faaliyetler gibi genel giderler kavramını ortadan kaldırır. Baştan sona kadar geçen süreden ziyade, yalnızca kesintisiz olarak bir şey üzerinde çalışsaydınız ne kadar süreceği üzerine odaklanır.

Tipik olarak, bir proje hakkında en az şey bildiğimizde yüksek düzeyde tahmin yaparken, ideal günlerde tahminde bulunuruz çünkü bu, hikaye noktası gibi soyut bir sayı yerine geçmiş tarih ve deneyimle ilişkilendirilmesi daha kolay bir kavramdır. Özellikle yüksek düzeydeki hikayeler, doğası gereği çok az ayrıntıya sahip ve daha sonraki bir tarihte parçalandığında muhtemelen ek öğeler içeren destanlar olduğunda.

Daha ayrıntılı bir düzeyde tahmin yaparken, yerleşik bir ürün birikiminde bir hikaye söyleyin, her iki yaklaşım da kullanılabilir ve mühendislik ekibi tarafından kararlaştırılacaktır. Her iki yaklaşımın da faydaları vardır ve her takımın kendi tercihi olacaktır.

Tahmin Teknikleri

Paylaşılan Tahminler Tahminler tek başına yapılmaz. Tüm mühendislik ekibi tarafından birlikte işbirliği içinde gerçekleştirilirler ve tasarım, veritabanı, sunucu, ön uç kullanıcı arabirimi, kalite güvencesi ve diğer işlevler arası uzmanları içerirler. Bu, bir özelliği tamamlamak için ilgili işin tüm yönlerini dikkate almama sorunlarını önler ve hiç kimsenin bir özelliğin boyutunu gereğinden fazla veya hafife alma yükü veya talihsizliği yaşamamasını sağlar. Kombine ekibin tümü, tartışılabilecek ve üzerinde anlaşmaya varılabilecek bir görüşe sahip olacaktır.

Benzer Tahminler Bu, iki ayrı özelliği göz önünde bulundurduğumuz ve birinin diğerinden nispeten daha küçük veya daha büyük olduğuna karar verdiğimiz yerdir. Belirli bir hikayeye bakabilir ve boyutunun küçük olduğu konusunda hemfikir olabiliriz ve hikaye puanlarını kullanırsak ona iki boyut verebiliriz. Bir sonraki hikaye, birincisine kıyasla daha büyük olarak kabul edilebilir ve biz ona beş boyutunda veririz. Bu, büyük bir özelliğin küçük bir özelliğin boyutunun en az iki katı olduğunu gösterir.

Bu alıştırmaya tüm hikayelerle devam edeceğiz. Tamamlandığında, tüm küçük, orta, büyük ve ekstra büyük katları yan yana yerleştirebilir ve tahminimizde bir tekdüzelik düzeyi olduğundan emin olmak için boyutlandırmamızı çapraz kontrol edebiliriz.

Planning Poker Planning Poker hakkında çok şey yazıldı; Bir önceki blogumda da bahsetmiştim. Bunu anlamak için en iyi kaynaklardan biri burada.

Özünde, uzman görüşü, analoji ve ekip işbirliğini kolay, hızlı ve güvenilir bir süreçte birleştirir.

Teknik ve alan deneyimine, canlı bir diyaloga ve sağlam bir gerekçeye dayalı bir tahmin oluşturmaya en uygun birden fazla uzmanı bir araya getirir.

Hız

Hız, bir takımın belirli bir yinelemede (veya sprintte) işi tamamlama kapasitesinin bir ölçüsüdür.

Bir aralık olarak ifade edilir, örneğin, özellikle bir projenin başlangıcında, sprint başına 23 ila 32 hikaye noktası. Genel olarak bunun nedeni, aynı ekip daha önce aynı problem üzerinde çalışmadıkça, ekibin hızının tam olarak ne olacağını tasvir etmenin zor olmasıdır. Dikkat edin, bir kişinin hızından değil, bir takımın hızından bahsediyoruz!

Bir projede ilerlerken yayınlarımızı planlamak ve planlarımızı ve iş paketlerimizi uyarlamak için hız kullanırız, böylece yürütme yoluyla tamamlama tahminimizi düzenli ve doğru bir şekilde ayarlamamızı sağlarız.

Başladığımızda, çok az veri ile bir hız aralığı tanımlamaya zorlanıyoruz. Takım ve problem alanı aynıysa, ki bu genellikle en düşük ihtimaldir, tarihsel değerleri kullanabiliriz. Aslında proje üzerinde çalışan bir ekipten hız hakkında bir fikir edinmek için bir yineleme çalıştırabiliriz, ancak bu maliyetlidir ve bir projeyi başlatma konusunda karar verilmesi gereken kararlar varsa işe yaramaz. Veya bir tahminde bulunabiliriz.

Bir hız tahmini, bir sprint değerindeki hikayeleri almayı ve bunları hikayeyi tamamlamak için gerçekleştirilen görevlere bölmeyi içerir. Tasarım, geliştirme, test etme vb. dahil olmak üzere her görevin alacağı saat sayısını tahmin eder ve ekibin belirli bir sprintte ne kadar kapasiteye sahip olacağını değerlendiririz. Engelsiz bir ekip için yüzde 70'lik bir kapasite iyi bir temeldir. Yani, basit bir durumda, takımın kullanabileceği toplam saat:

• 4 ekip üyesi * iki hafta * haftada 40 saat = 320 saat
• Yüzde 70 kapasitemizle çarpılır = 224 saat
• Tüm özellik görevlerini toplayın ve 224'te saymayı bırakın
• Tamamlanan tüm özellikleri alın, hikaye puanlarını toplayın ve hızınızı elde edin, diyelim 36
• Tahmini 29 ila 43 hikaye noktası hızına ulaşmak için en düşük ve en yüksek aralığı elde etmek için her iki tarafa da yüzde 20 uygulayın.

Hız genellikle ilk iki ila dört yinelemede değişir ve daha sonra küçük bir nokta aralığında sabitlenir. Bu nedenle, birinci sprintten önceki ilk aralığımız, sprint dördünde 29 ila 43 iken, 34'ten 38'e plato olabilir. Bu, bize son tamamlanma tarihimizi tahmin etmede daha fazla güven verir.

Risk ve Belirsizlik için Arabelleğe Alma Planları

Tüm yazılım projeleri bir miktar belirsizlik içerir. Projede ilerledikçe bu belirsizlik azalır ve teknolojimiz, çevremiz, performansımız ve müşterinin ve kullanıcıların ihtiyaçları hakkında daha çok şey bilinir.

Bu belirsizliği veya riski, tahminimizde bir hata marjını ve geliştirme başlamadan önce belirleyemediğimiz bilinmeyenleri hesaba katan programdaki bir tamponla azaltıyoruz.

Tipik olarak iki arabellek türü vardır: Özellik ve Zamanlama. Genellikle sabit bir teslimat tarihi için sabit bir fiyat tanımladığımızdan, Özellik arabelleğini kullanmak tercih edilir.

Bu yaklaşım bize güvenilir bir risk azaltma stratejisi sunar ve proje tamamlandığında bir sonuç olarak ne görmeyi beklemeleri gerektiği konusunda müşteriye güven verir.

Özellik Tamponları

Bir özellik arabelleğiyle, belirli bir özellik kümesi sunacağımızı, ancak ideal olarak bir başka özellik kümesini tamamlayacağımızı tahmin ediyoruz. Bu, en azından müşterinin geçerli bir ürünü piyasaya sürmek için gerekli gördüğü minimum özellik setini yansıtmalıdır, ancak tüm çeşitli iç ve dış etkiler izin verirse, zaman çerçevesi içinde daha fazlası teslim edilebilir.

Bu nedenle, bir müşteri, ürün biriktirme listesinden en yüksek öncelikli özelliklerin, 100'e kadar hikaye noktası ekleyerek en önemli olduğuna karar verebilir. Daha sonra 30 hikaye puanı ekleyen ek özellikleri değerlendirebilirler. Bu nedenle ekip, verilen sabit fiyatlı sözleşme için planlanan tamamlanma tarihinin sonunda en az 100 olmak üzere 130 hikaye puanı teslim etmeye dayalı plan yapacaktır.

Bazı kapanış düşünceleri

Çevik, tam olarak kavraması ve benimsemesi çok zor bir kavram olabilir. Fiyat, kapsam ve süre gibi hassas konuları yönetirken bu durum daha az geçerli değildir. Ne yazık ki, talepkar müşterilerin her şeyin önceden düzeltilmesini istediğini ve her şey çözülmeye başladığında tedarikçiyi suçlamaya istekli olduklarını ilk elden biliyorum. Aynı şekilde, peşini bırakmayan, tepkisizleşen ve müşteri ihtiyaçlarına yanıt veremeyen satıcıların da farkındayım. Çevik bir yol almak temelde güven, iyi ilişkiler ve mükemmel iletişim üzerine kuruludur. Bunlar, katılan herkes için eşit fayda, memnuniyet ve başarı için sağlıklı bir projeyi sürdürmek için her iki tarafça da sahip olunan değerler olmalıdır. İşbirliği ve müzakereye karşı açık fikirli ve yapıcı bir tutum sergilemek, ilişkilerin kötüye gitmesini önlemenin en iyi yoludur.

Çevikliğin uyarlanabilir doğasını benimsemeyi ve komuta ve kontrol tavrından vazgeçmeyi zor bulan müşterilerle çalıştım. Tüm inancınızı ve güveninizi tanımadığınız bir takıma bırakmak zor. Çoğu zaman, müşteriler, teslim edilecek şeyin bir özelliği olarak tüm gereksinimleri önceden oluşturmak isteyebilirler. Bu onlara bir projenin kapsamının iyi tanımlandığına dair bir güven duygusu verir. Ancak nihayetinde bu başarılı bir yaklaşım olarak hayata geçmemektedir. Bir sözleşmede kapsam ve gerçekçi olmayan taleplere kilitlenirsek, sorunlar çok çabuk ortaya çıkar.

Geleneksel yöntemlerde bu yaklaşımı benimserken, kapsamın değiştiğini, bilinmeyenlerin ortaya çıktığını veya müşterinin istediğini düşündüğümüz şeyin artık doğru veya işaretten uzak olmadığını biliyoruz. Fiyatlandırma, planlama ve kapsam konusunda uyarlanabilir bir yaklaşım benimsemek, müşterilerin ürünlerini tam olarak pazarlarının ihtiyaç duyduğu şey olarak tanımlamalarına olanak tanır. Bir satıcının da duyarlı, yaratıcı ve verimli olmasını sağlar. Sözleşme müzakeresi üzerinden müşteri ve satıcı arasındaki işbirliğini kullanmak çok önemlidir.

Satıcılar dürüst olmalı ve müşteriler en başından nelerin elde edilebileceği konusunda gerçekçi olmalıdır. Gerçekçi olmayan hedefler vaat eden ve ardından maliyetleri artıran bir satıcı ilk sözleşmeyi kazanabilir, ancak kısa süre sonra hoşnutsuz bir müşterinin desteğini kaybedecektir. Çoğu zaman, taraflar arasındaki güven eksikliği veya güven eksikliği nedeniyle ilişkiler bozulur. Güven, baştan inşa edilmeli ve bir proje boyunca sürdürülmelidir. Bir satıcı esnek olmalı ve değişen ihtiyaçlarla işbirliği yapmalıdır. Müşteriler her zaman daha fazlasını ister; iş yapmanın doğal bir sonucudur. Her iki taraf arasında eşit ve faydalı bir değer değişimi olmalıdır. Müşteriler için, işletmeleri için değer yaratmak istiyorlar. Satıcılar için müşterilerle uzun süreli ilişkiler kurarak değer yaratmaya çalışmalılar. Çevik Manifesto'nun değerlerine ve yol gösterici ilkelerine uymak, güçlü, dengeli ve uzun ilişkiler kurmak için sağlam bir temeldir.

Özet

Umarım bu size bir Çevik yazılım projesi için bir fiyat planlama, tahmin etme ve tanımlama konusunda biraz fikir vermiştir. Yukarıdaki yaklaşımların ve tekniklerin tümü, bir takımda güven oluşturmak ve bir yazılım ürünü oluşturmanın ne kadar süre ve ne kadar süreceği konusunda müşterilerin zihninde güven oluşturmak için tasarlanmıştır. Ve nihayetinde, devam etme kararı verme konusunda güven oluşturmak.

Bu yönergeleri izleyin ve yazılım ürününüzü hayata geçirmek için tatmin edici bir yol bulacağınızdan emin olabilirsiniz.