İçindekiler:
yazılım projesi tahmini
Pixabay
Giriş
Tahmin etmek çok zor. Ne yazık ki, aynı zamanda çok gerekli. Şirketler, sürüm programlarını planlamak, müşterilerine taahhütlerde bulunmak, önerilen bir özelliğin uygulamaya değer olup olmadığına karar vermek, ekiplerin hızını izlemek ve işe etkili bir şekilde öncelik vermek için tahminler kullanır. Yöneticiler genellikle bir özelliğin veya teslimatın ne zaman üretime hazır olacağını bilmek isterler. Sonuçta, yazılım geliştirme önemsiz bir yatırım değildir. Tahminler olmadan, proje yöneticisi nasıl bir değerlendirme yapar? İnsanlar geleceği doğru tahmin edebilselerdi, insanlar at yarışlarında% 2 oranında kazanamazlardı. Tahmin, büyük muammadır. Şirketlerin insanlarından imkansızı yapmasını istemesi çok önemli ve gereklidir: geleceği tahmin etmek.
Öncelikle, bazı popüler tahmin yöntemlerini gözden geçirelim (heyecanın bir kısmını kaçırdıysanız). Daha sonra bunun bizim ve projelerimiz için ne anlama geldiğine bakabiliriz.
Falcı Modeli
Bu model, bir tahmin oluşturmak için neredeyse hiç çaba gerektirmez. Tahminciler, bir özelliği uygulamak ve test etmek için ne yapılması gerektiğini biraz düşünür ve ardından bir sayı atarlar. "… (uzun duraklama)… Ummmmm… 6 hafta" gibi bir ses geliyor. Sonra herkes başını salladı ve devam ediyoruz. Ön tarafta, gereksinimler hakkında bildiklerini konuşarak epey bir zaman geçirebilirler (ki bu muhtemelen resmin tamamı değildir). Bu dikkatli analiz, tahminlerini daha güvenilir hale getirir. Projenin sonunda, tahminin neden gerçeklikten bu kadar uzak olduğuna dair her zaman kabul edilmiş bir mantık vardır. Her zaman günah keçisi görevi görebilecek öngörülemeyen durumlar vardır. Çoğu zaman, modelin ciddi şekilde kusurlu olduğu kimsenin aklına gelmez.
Peki bu süreci nasıl daha iyi hale getirebiliriz? Biliyorum! Ayrıştırma Tekniğini kullanabiliriz (yani böl ve yönet). Bu yaklaşım, ön uçtaki özelliğin veya projenin tüm kapsamını bildiğinizi varsayar. Her özellik, küçük parçalara bölünmüştür. Her parça tahmin edilir (falcı stili), ardından genel bir özellik / proje tahmini elde etmek için bunları ekleriz. Bu kesinlikle daha karmaşık bir yaklaşım, ancak iki nedenden dolayı daha iyi görünüyor:
- Daha küçük iş parçalarının güvenilir bir şekilde tahmin edilmesi daha kolay olma eğilimindedir.
- Hala hata fırsatı (+/- bir miktar) olsa da, hepsini topladığınızda hataların birbirini iptal edeceği ve daha güvenilir bir genel tahmin alacağınız varsayımı vardır.
Bu yaklaşımın temel kusuru, bireysel katkıda bulunanların (işi gerçekten yapan kişilerin) evrensel olarak hafife almasıdır. Yine de üstlerindeki ve etrafındakilerden önemli ölçüde daha iyidirler, ancak bu yüksek bir çıta değil. Durum böyle görünmüyor çünkü hepimiz geliştiricilerin programın ilerisinde bir şeyler başararak kendilerini şaşırttığı durumlar gördük. Ancak bu tek bir veri noktasıdır, bir eğilim değil. İnsanlar aslında kumarhanede ara sıra kazanır; bir yıl boyunca her gün bir kumarhanede para harcarsanız, başladığınızdan daha az paranız olur. Bir veya iki yıl boyunca tahminleri ve gerçekleri izlerseniz, tahminlerin gerçeğe aykırı olduğunu keşfedeceksiniz. Pek çok iş adamı, geliştiricilerin tahminlerini tembel bir şekilde doldurduklarından ve ekstra zamanı "altın plaka" yapmak veya stoklarını kontrol etmek için kullandıklarından kesinlikle emin olsa da,veriler aksini gösteriyor. "İptal etme" stratejisi işe yaramıyor.
Peki şimdi ne olacak? Falcı modelini terk edelim ve boyut temelli bir yaklaşıma geçelim. Görünüşe göre, insanlar tamamlanma süresini tahmin etmekte oldukça kötü olsalar da, aslında bir şeyin ne kadar büyük olduğunu söylemekte oldukça iyiyiz. Karşılaştırmalı boyutlandırma konusunda özellikle iyiyiz ("bundan daha büyük ama oradakinden daha küçük"). Zaman yerine boyut veya karmaşıklık açısından düşünürsek, beynimiz bunu daha güvenilir bir şekilde işler. Daha sonra boyut değerlerini alabilir ve şık bir sihirli formüle dayalı olarak proje için gerçek saat sayısını hesaplayabiliriz! İşte o zaman popüler fonksiyon noktaları modeli sahneye girer (sahne solda).
Fonksiyon Puan Analizi (FPA)
Fonksiyon noktası analizi için, uygulamamızda beş tür şeyi tanımlamamız gerekir: harici girdiler, harici çıktılar, harici sorgular, harici arayüz dosyaları ve dahili mantıksal dosyalar (tanımlar hakkında çok fazla endişelenmeyin; bunları daha sonra araştırabilirsiniz). Bunların her bir örneği (bir işlev) kendisiyle ilişkili bir karmaşıklığa sahiptir (düşük, ortalama veya yüksek). Her bir işleve kaç nokta atandığını bulmak için aşağıdaki tabloyu kullanıyoruz.
Şimdi tüm işlevlerimiz için puanları toplarsak, projemiz için 457 işlev puanı gibi bir sayı elde edebiliriz. O zaman saat sayısını hesaplamak için bir formüle ihtiyacımız var… Son projemize göre, “teslimat oranımız” kişi başına ayda 15 fonksiyon puanıydı. Bu kabaca 30 aylık bir çalışma, 12 kişilik ekibim için iki buçuk aydan biraz fazla zaman alacaktır. Ta-da!
Bu kesinlikle önceki modelimizden daha karmaşık. Aslında, anlaşılması gereken dört temel karmaşık alan vardır.
- Beş bileşen türü mutlaka sezgisel değildir ve listeye bir şey koymayı veya onu yanlış kovaya atamayı unutmak kolaydır.
- Gerçekte işlev noktalarını oluşturmak için kullanılan tablo, doğrulamak için çok çaba gerektiren sihirli sayılar içerir. Ekiplerim için güvenilir tahminler oluşturmak için bu sayılar uygun şekilde kalibre edilmiş mi?
- Teslimat oranı (bulmacanın kritik bir parçası) ekibinizin üretkenliğine göre hesaplanır. Yeni bir sayıyı ne sıklıkla hesaplamamız gerekiyor? Aslında bu konuda çok az rehberlik var.
- Düşük, ortalama veya yüksek karmaşıklığı neler oluşturur? Herkesin anlaması için bunu nasıl tanımlarız? Hesaplamalarımızın doğruluğu için bunu doğru yapmak kritik değil mi?
Bu çok basit örnekte birkaç hareketli parça var ve daha karmaşık karmaşıklık modellerini ve devreye girebilecek diğer verileri (ör. Maliyet oranı, destek oranı, kusur yoğunluğu vb.) Tartışmadık bile. Daha fazla hareketli parça, hataların oluşması için daha fazla fırsat anlamına gelir. Şimdi tahmin yapmayı çok mu karmaşık hale getiriyoruz? Geliştiricilere, tahmine çok fazla zaman ayırmaları için para ödemiyoruz. Müşterilerime bir tahmin satamıyorum. Çalışan bir yazılıma ihtiyacım var. Orada başka bir şey var mı?
Çevik Olmak
Şimdi kısaca Agile scrum'a bakalım (sadece bir karşılaştırma yapmak için yeterli). Daha önce belirtildiği gibi, insanlar zamanı tahmin etmede çok kötüdür ve karşılaştırmalı boyutlandırma konusunda oldukça iyidir. İşte anlaşılması gereken birkaç terim:
- Sprint - zaman kutulu bir zaman dilimi (genellikle iki hafta).
- Kullanıcı hikayesi - ayrı bir iş parçası, tercihen bir sprintte bir kişi tarafından yapılabilecek kadar küçük. Tahmin ettiğimiz şey bu.
En popüler strateji, tahminler için bir fibonacci dizisi (0, 1, 2, 3, 5, 8, 13) kullanmaktır. Doğrusal değildir - ölçek yükseldikçe boşlukların boyutu artar. Kilit nokta, boşlukların yeterince geniş olması ve önemsiz farklılıklar üzerinde tartışmak için hiçbir neden olmamasıdır. 3'ün üzerine çıktığınızda, 4 ile 5 veya 7 ile 8 arasındaki fark o kadar önemsizdir ki, hangisinin olduğunu bulmak için zaman harcamak anlamsızdır. Bir taban-2 dizisi de işe yarar (0, 1, 2, 4, 8, 16, vb.).
Ama bekleyin, bu sadece bir sayı. Bu ne demek? Kaç saat bir noktadır? " Puanların doğrudan saatlerle ilişkilendirilmesi amaçlanmamıştır, çünkü eğer yaparlarsa, takımlar saat cinsinden tahmin yapmaya geri dönüp bunu bir şekilde noktalara çevirme eğiliminde olacaktır. Daha önce tartışıldığı gibi, tahminlerimizin doğruluğu karşılaştırmalı boyutlandırmadan ve bir şeyin alacağı saat sayısını tahmin etmemekten gelir. Takıma saatler bazında düşünme yeteneği verirseniz, doğru tahmin yapma yeteneğinizi tehlikeye atmış olursunuz.
Diyelim ki bir kalibrasyon alıştırmasıyla başladınız. Ekibinizi bir odaya çekin ve 10-12 kullanıcı öyküsünden oluşan bir listede onlara rehberlik edin. Küçük olanı seçin ama en küçüğü değil ve önce bunu yapın. İnceleyin ve bu hikayenin bir "3" olduğunu duyurun. Sormuyorsun Anlatıyorsun. Sonra bir sonraki hikayeye geçin. "Bu 3 ise, bu nedir?" Şimdi ekip hikayeleri diğer hikayelere göre boyutlandırıyor. Sonunda neyin “1”, “2” vb. Oluşturduğu konusunda oldukça iyi bir fikre sahip olacaklar. Tahmin yapmıyorlar. Zaman önemli değil. Hikayeleri, zaten bir numarası olan diğer hikayelere göre boyutlandırıyorlar. Daha sonra cetvel adı verilen bir belgede dizideki her sayı için örnek öyküler koyabilirsiniz. "5" in ne olduğundan emin değillerse bunu referans olarak kullanabilirler.
Şimdi işte anahtar. Bunun işe yaramasını sağlayan sihirli özellik "hızdır" (bir takımın 3-4 sprintte ortalaması alınan bir sprintte tamamlayabileceği puan sayısı). Sprintinizin iki hafta olduğunu ve 8 kişilik ekibinizin ortalama 35 puanlık bir hıza sahip olduğunu varsayalım. 640 saatlik çalışmada (8 x 80 saat) 35 puan alıyorsunuz. Bir özelliğin bitmeye başlaması için yaklaşık 100 puan değerinde bir iş alacağını anlarsak, bunun yaklaşık 6 haftalık çalışma ve ~ 1900 saat olduğunu biliyorum. Ekip, hikayeleri tutarlı bir şekilde boyutlandırmada çok başarılı oluyor ve siz bundan proje planlamanızı yapmak için yararlanıyorsunuz. Bu hesaplama işe yarar çünkü süre sprintten sprint'e kadar tutarlıdır.
Uzun vadeli üst düzey planlama yapmak için, potansiyel müşterilerinizden üst düzey özellikleri ara tek satırlık öykülere ayırmalarını ve bunlara puan değerleri koymalarını isteyebilirsiniz. Bir dereceye kadar doğruluk kaybı olacaktır, ancak zaten anladıkları modeli kullanıyorsunuz. Daha doğru bir yol, özellik düzeyinde göreceli boyutlandırma olacaktır. "Bu özellik, 40 puanlık özellikten daha büyük, oradaki 120 puanlık özellikten daha küçük ve az önce yaptığımız 65 puanlık özellikten biraz daha büyük." Hikayeler "destanlar" olarak gruplandırılmıştır. Her özellik bir destan ise, sonunda o özelliği tamamlamak için kaç puan gerektiğini bileceksiniz. Bunun bir geçmişini tutun ve bunu sürüm planlamanız için kullanabilirsiniz.
Sonuç
Bugün kullanımda olan birçok metodoloji var. Her birinin artıları ve eksileri vardır. İyi kararlar alabilmek için bir şekilde tahminlerimizin doğruluğunu nasıl en üst düzeye çıkaracağımızı bulmalıyız. Bu, tahminlerimizin doğru olması gerektiği anlamına gelmez. Sadece işe yarayacak kadar doğru olmaları gerekiyor. Tahmini anlamazsanız, tahminlerin doğru olmadığını varsayabilirsiniz çünkü takım iyi bir iş yapmamıştır. Doğru tahmin etmediler veya projeyi doğru şekilde yürütmediler. Tahminler iyileşene kadar dayak devam edecek. Ancak tahminler asla bir taahhüt olarak kullanılmamalıdır. Bugün sahip olduğumuz sınırlı bilgiye dayalı en iyi tahmin. Yeni bilgiler ortaya çıktığında, tahminlerin yeniden gözden geçirilmesine izin vermeliyiz. Başka herhangi bir şey imkansızı beklemektir, bu da liderlikle ilgili bir sorundur (takımla değil).
Scrum'ın yaklaşımı, fonksiyon noktaları analizinde gördüğümüzden çok daha basittir. Ve bunun sihirli sayılara sahip sihirli masalardan çok daha güvenilir olduğunu söyleyebilirim. Paranın karşılığını en iyi şekilde alır (oldukça yüksek bir doğruluk derecesi ile minimum çaba). Efor açısından bakıldığında, ekiplerin anlaması ve kullanması için ağır bir süreç yaratmaz. Agile'ın tahmin parçası, tahmin edilen işin ayrıntılarını herkes anladığında gerçekten çok hızlı gerçekleşebilir. Kesinlikle sayıları havadan çekmekten daha iyidir. Hızdan yararlanmak çok önemli bir şey yapar: hesaplamaya geçmiş verileri getirir. Her sprint, hızınızı yeniden hesaplarsınız. Bu kritiktir çünkü zamanla iş hacmi değişir. FPA kullanan ekipler teslimat oranlarını önceki projelerinden elde edebilir,ki bazı durumlarda birkaç ay önceydi. O zamandan beri muhtemelen çok şey değişti. Benim önerim, Agile'ı keşfetmeniz ve hikaye noktalarını ve hızını anlamak için gerçekten çaba göstermeniz. Saatlerce tahmin etmeye geri dönmeyin çünkü anladığınız şey bu. Kendinize daha sonra teşekkür edeceğinize inanıyorum.