Daha iyi tahminler yapmayı nasıl öğrenirim? [kapalı]

Tahminlere emilirim. Biri bana ne kadar uzun süreceğini sorduğunda, tamamen işaretsiz kalacağımdan bir tahmin yapmaya bile cesaret edemiyorum. Genelde çok iyimserim ve muhtemelen tahminlerimi büyük bir X faktörü ile çarpmalıyım ...

Daha iyi tahminler yapmayı nasıl öğrenebilirim? Üniversitemde öğretilmedi ve tüm çalışmalar için son teslim tarihlerimiz olmasına rağmen, bir şeyin gerçekte ne kadar süreceğini asla düşünmüyorum. Yapmam gereken şey. Herkesin iyiliği için (özellikle benim).

Hala bunda iyi değilim, ancak görevler için ne kadar zaman ayırdığınızı ve gerçekte ne kadar sürdüğünüzü izlemenin size yardımcı olabileceğini öğrendim. Bu şekilde genellikle ne kadar uzakta olduğunuza dair sağlam bir fikir edinebilirsiniz. Zaman izlemeli sorun yönetimi yazılımı (benim durumumda Jira) veya elektronik tablo bu konuda çok yardımcı olabilir.

Bence her şeyden çok bir deneyim meselesi.

Zaman Yönetimi Murphy Yasası: Uzun bir şeyler anlamaya için olacaktır , ne kadar süre saptamayla almak gerekir alıp ikiye katlayın.

Ardından bir sonraki yüksek zaman birimine geçin. Bu nedenle, bir günlük bir projeye iki hafta ayırıyoruz.

Toplu olarak yaparak öğrenebilirsiniz .

Kullandığım Planlama Poker . Bu tahmin için bir fikir birliğine dayalı teknik.

Tahmininiz izlenmeli ve etkili bir şekilde yaptığınızla karşılaştırılmalıdır. Hızı alacaksın .

Bir şeyi ne zaman tahmin ederseniz, doğru bir tahmin için son hızınızla çarpın .

Steve McConnell (MS Press) tarafından Yazılım Tahmini iyi bir okumadır.

Yazılım tahmini ile ana şey aşağıdaki tarafından özetlenir

Tarihsel bilgi olmadan, tahminlerin işe yaramaz.

Bu, yinelemeli projelerin neden büyük aşamalı şelale projelerinden daha fazla başarıya sahip olduğunu düşünüyorum. Olması gerektiğini düşündükleri kara kutu vudu dışında çok az bilgi içeren bir zamanda bir yıl boyunca bir plan yapmaya çalışmıyorlar. Her yineleme, yeniden tahmin ediyor / yeniden planlanıyor ve tahminlerini temel alan son birkaç yinelemeye sahipler.

Akılda tutulması gereken birkaç nokta:

1. Sadece yavaşlayacak . 80/20 kuralının uygulanması, proje yönetiminiz çok disiplinli olmadıkça, daha zor çalışmaların gerçekleştirileceği anlamına gelir .
2. Tahmin! = Planlama. Tahmin, bir şeyin yapılması için gereken çabayı bulma sürecidir. Planlama, bir takvime sığdırma sürecidir.
3. % 60 verimlilik, umut edebileceğiniz her şey hakkında. % 70 ütopyadır. Günler içinde tahminde bulunuyorsanız, bunu oluşturun. Saat olarak tahmin ediyorsanız daha sonra uygulamayı unutmayın.
4. Uzun kuyruğu unutma . Tahminler, “muhtemelen” ne kadar süreyle bir risk seviyesi ve bilinmeyenler için düzeltilmiş olacağı konusunda kaba bir tahmindir. Uzun kuyruk devreye girer çünkü gerekli iş miktarı hiç bir zaman 0'dan az olamaz. OTOH, alacağı maksimum süre sadece vazgeçmeden önce ne kadar zaman harcamak istediğinize bağlı olarak sınırlıdır. Eski bir patronumun dediği gibi "tüm tahminler +/-% x ve asla eksi değil".

Robert Martin The Clean Coder'da açıklanan PERT tarzı tahmin tekniğinden kimsenin bahsetmediğine şaşırdım . Bu yöntemde 3 senaryo için ne kadar zaman alacağını tahmin edersiniz: iyimser ( O), nominal ( N) ve kötümser ( P). Sonra beklenen süre = (O+4N+P)/6ve standart bir sapma olsun (P-O)/6.

Bu oldukça iyi çalışıyor gibi görünüyor ve yönetim bir şeyin muhtemelen ne kadar süreceği konusunda gerçekten umursadığı zaman birkaç kez kullandım.

Diğerlerinin de söylediği gibi, tarihsel verileri inceleyerek de tahminler yaptım ("Bu benzer şeyi yapmak ne kadar sürdü?").

Fakat en sevdiğim yöntem, zaman tahminlerini hiç yapmamak ve sadece nokta tahminlerini yapmak ve yinelemelerin üzerinde bir hız almaktır. Eğer bir ekip çalışmayı boyutlandırma ve tamamlama konusunda oldukça tutarlıysa (kullanıcı hikayeleri), o zaman her şeyin ne kadar süreceğini sorarak bile zaman kazanmazsınız.

Saat tahminleri doğru bir şekilde elde etmek için son derece zordur ve etkin bir şekilde ölçmek için işleri yeterince küçük parçalara bölmek için çok fazla çalışma gerektirir. Ve o zaman bile nadiren doğrudurlar çünkü çok fazla değişken vardır ve hastalık, tatil ve hatta dikkat dağıtıcı şeyleri hesaba katmayı unuturuz.

Saat tahmini yapmak zorunda kalırsam, bunları sadece bir yineleme içindeki ufacık işler için yapmaya çalışırım. Daha az olabileceğini bilmediğim sürece her şeyi yarım günlük tahminlerde (4, 8, 12 saat) ölçerim. Ancak nadiren 1 saatten daha az bir şeyi tahmin ediyorum.

Öncelikle ve en önemlisi, bir süreç tanımlamanız ve ona bağlı kalmanız gerekir. Sürecin her aşamasının sonunda planı revize et. Süreci de revize edebilirsiniz, ancak düzenli bir şekilde.

İkincisi, bir çeşit tasarım yapın. Tasarım, planlamanın ilk adımıdır, çizimleri olmayan bir ev yapmazsınız.

Üçüncüsü, izleme süresi (efor). En azından ayırt etmelisin:

• analiz
• tasarlamak
• kod
• Birim testi (sabitleme kusurları dahil)
• Entegrasyon testi (düzeltme kusurlarını dahil)

• Kullanıcı ile kabul testi (sabitleme kusurları dahil)

  Her test türü için kusurları düzeltme eforunu ölçtüyseniz harika olurdu, ancak karmaşıklığı ekler, böylece daha sonra yapabilirsiniz.

Dördüncüsü, tahmin için temel kalemleri tanımlayın. Örneğin:

• Otomatikleştirilecek işlem sayısı (Analiz)
• Etki alanı modeli varlıklarının sayısı (Tasarım)
• Form ve rapor sayısı (Kod)

Beşinci olarak, temel öğeleri ve eforu ilişkilendirin. Örneğin:

• Analiz çalışması = X adam-saat / işlem otomatikleştirilecek
• Tasarım çalışması = Y adam-saat / etki alanı modeli varlığı
• Kod çalışması = Z adam-saat / form (veya rapor); form sayısı = A * etki alanı modeli varlıkları
• Birim test çabası =% M * Kod zahmeti
• Entegrasyon testi çabası = N% * Kod çabası
• Kabul testi çabası = P% * Kod çabası

Altıncı, performans ve her proje için tahminlerden sapma takip edin. Böylece korelasyon faktörlerinizi ince ayar yapabilirsiniz.

Yedinci, tekrarla ve geliştir. Sadece ilk projenin sonunda çok fazla fikir edineceksiniz, üçüncüsü ile planlama ve tahminde bulunmaktan rahat hissedeceksiniz.

Http://en.wikipedia.org/wiki/Personal_Software_Process'e bir bakın, gerçekten işe yarıyor.

Bir tahmin problemiyle karşılaştığınızda, onları daha küçük parçalara bölmeye çalışın. O zaman bakalım, parçalara benzer şeyler yaptınız mı? Eğer varsa, zaten her bir parçanın ne kadar sürdüğü hakkında net bir fikriniz olmalı. Bunu yapmazsanız, çeşitli görevler için harcanan zamanı etkin bir şekilde takip etmeye başlamalısınız. Bu, gelecekteki tahminlerde size yardımcı olacaktır.

Gerekli olan toplam süre, parçaların toplamından daha fazla olacaktır, çünkü entegrasyon ve test için biraz zamana ihtiyacınız vardır.

Benzer bir şey yapmadıysanız, muhtemelen diğer insanların deneyimine güvenebilir ve onlardan bir tahminde bulunabilirsiniz. Gerçi bunu yüz değerinden almayın. Hiçbir şey sana tecrübe sevdiğini öğretemez.

Hedefi vurmak gibi bir şey. Tahminde bulunan önceki çekimler size notun ne kadar kapalı olduğunu söylemelidir, böylece düzeltebilirsiniz.

Her biri için yukarıda belirtilen asgari görevlere bölünme işlemini yapmanın en kolay olduğunu düşünüyorum ve sonra bu tahminde iki katına çıkın. Sonra onları birleştirip yüzde elli ekledim. Bu bana ideal koşullarda yaklaşık bir proje süresi verir. Eğer iş pratik olarak diğerleriyle paralel olarak gerçekleşecekse, daha uzun zamana ihtiyacı olacaktır. Diğer insanları beklemek zorunda kalacaksanız, düşündüğünüzden iki kat daha almalarını bekleyin. İçeriği veya geri bildirimi veya diğer bilgileri beklemek çoğu zaman mümkün göründüğünden çok daha uzun sürer.

Çalıştığım yerde, sürecin her adımı için en iyi durum / beklenen durum / en kötü durum tahmini olarak çalışıyoruz, bu da bir rehber olarak ve ayrıca tahminlerinizin nasıl yürüdüğünü değerlendirmek için kullanışlıdır.

Program, programcının görevlerini hafife almakla cezbedici ile mücadele edebilmeniz dışında, teknik o kadar önemli değildir, ancak önemli olan şey, ne zaman bir şey sunabileceği konusunda muhafazakar olmaktır. Bir şeyi inşa etmeniz yedi hafta sürüyorsa ve sekiz hafta söz verdiyseniz, biraz erken gelebilir ve bunun için iyi görünebilir veya bazı ekstra testler yapabilir ve güvenilirlikten emin olabilirsiniz. Altı hafta söz verdiysen kesinlikle senin suçun olmasa bile kötü görünebilirsin. Şüphe durumunda, muhafazakar tahmin edin.

Tahminin ne olduğunu ve listenizde tekrarlanan belirli şeyler için ne çarpanı olduğunu bilmek için bir kayıt oluşturabilecek kadar çeşitli görevler için gerçek olanı izleyebilmeyi deneyebilirsiniz. Bunun bir deneme yanılma alıştırması olduğu kabul edildi, ancak benim için iyi sonuç verdi. Desen muhtemelen ortaya çıkmadan önce birçok deneme için söylenecek bir şey var. Bu muhtemelen birinin "Sadece yap!" Diyebileceğini söyleyen birçok cevaba benzer. bu gerçekten çoğumuzun yeteneğini nasıl geliştirdiğimize bağlı. Tahminde bulunurken ne kadar yanlış olabileceğini görmek büyük bir acı mı? Evet, ancak tahminler iyileşirse, sonunda herkes mutlu olabilir.

Projeyi daha küçük görevlere ayırabilirseniz ve bunlar için tahminler yaparsanız, her şeyden daha doğru olursunuz. Birkaç günden daha büyük olan işler daha da bozulur. Eğer onu daha fazla kıramazsanız, muhtemelen bir ihtiyaç boşluğunuz vardır. Tek satırlık bir ihtiyaç için iyi bir peçete tahmini yapmak zorundaysanız ... hiçbir şey size gerçekten yardımcı olamaz. Ne yazık ki pek çok dükkan çoğu zaman bu şekilde çalışıyor.

Üzerine bir kitap yazmak yerine, "yıkılma" tahmin yönteminin nasıl kullanılacağı hakkında biraz öneride bulunacağım:

• Atamanızı daha küçük bileşen görevlerine bölün. Her görevi mümkün olan en iyi şekilde tahmin edin.

• Planlama ve tasarım için bir görev ekleyin (şu anda ne yaptığınızı içerir). Tahmini yapın.

• Zaten bir göreviniz yoksa, "görevleri bir araya getirmek" için bir görev ekleyin. Bu görev ilk başta kullanışlı görünmeyebilir. Bununla birlikte, bu "yıkılma" tahmin yöntemini kullandığınızda, "görevleri arasına giren" ve "görevleri bir araya getiren" şeyler yapmak için her zaman zaman alıcı şeyler vardır. Bu bir tahmin etmek zor olabilir. Elinden gelenin en iyisini dene.

• Test ve dokümantasyon için bir görev ekleyin. Göreviniz çok fazla test ve dokümantasyon gerektirmeyebilir, ancak en azından biraz düşünmek zorundasınız.

• Genel bir tahmin almak için görev tahminlerini toplayın.

• Devam edin ve bu toplam tahminin iki †† ile çarpın. Bu size dolum zamanı verecektir:

  1. Orijinal görev listenizde gözden kaçan şeyleri bitirin
  2. Başa çıkana kadar bilmediğiniz şeyleri bitirin
  3. Diğer insanlardan geri bildirimler ekleyin ve değişiklikler yapın
  4. Toplantılar gibi çevrenizde olup bitenlerden rahatsız olun
  5. Tahmin etmeyi geride bıraktığınızdan daha sık bitirin.

Ve sonuncusu, fakat en az değil, muhtemelen tamamen yanlış olan tahminleri kendiniz çizmekten korkmayın. Bazen ne kadar çılgınca yanlış olursa olsun, sadece her şeyi eskiz etmek, katılanlar için daha iyi bir anlam kazanma yolunda başlamanıza yardımcı olabilir.

†† Daha fazla tecrübe kazandıkça, bu "geçiştirici faktör" kişisel tarzınıza ve çalışma ortamınıza uyacak şekilde ayarlanabilir.

Kendim için çalışırken çalışan formül:

1. yapılacakları 1 - 4 saatlik bir parçalığa ayırın. Bunlarla genellikle doğru olduğumu biliyorum

2. 'bilinmeyenler faktörü': Bilinmeyenlere yükseltilmiş 2 faktörüyle çarp. Yani bir couchdb uygulaması geliştirmek, ancak şimdi javascript ve http hakkında bir şey biliyorsanız, çok faktör olarak 2 ^ 2 ekleyin.

3. context-switch-factor: Mükemmel bir ortamda (evde çalışma köşesinde vb.) çalışacaksanız 1,5'e veya kusurlu bir ortamda çalışacaksanız 2,5'e (ofis / kalabalık yer vb.)

Bunu, gerçek zamanın +/-% 20'sinde buluyorum !!

Kendi önyargınızı öğrenin. Son tahminin iki kat faktörü ile çok düşük olması durumunda, bir dahaki sefere ilk tahmininizi ikiye katlayın. (Tabii ki, Hofstadter'ın yasası bu hakkı yapmayı zorlaştırıyor ...)

Aynı zamanda, önceki çalışmanın ilk yayınlanmasından sonra ne kadar işin gerekli olduğunu hatırlamak ve bir sonraki tahminde bunu eklemek de iyi bir fikirdir. Örneğin, son görevinizin tamamlanması 2 ay sürdü, ancak canlı yayına geçtikten sonra, destek, düzeltmeler ve ek değişiklikler size bir ay daha mal oldu, bu yüzden bir dahaki sefere benzer bir görev için 3 ay tahmin et.

Açanlar için, Barry Boehm'den "Yazılım Mühendisliği Ekonomisi" ve Tom DeMarco'dan "Kontrol Yazılımı Projeleri" ni okuyun. Bu ikisini okuduktan ve sindirdikten sonra, Barry Boehm tarafından yazılan "COCOMO 2 ile Yazılım Maliyet Tahmini" ni okuyun.

Daha sonra söyleyeceklerim için, olasılık ve istatistik dersi, hatta temel bir yemek kitabı olan bir LOT'a girmenize yardımcı olacak.

Hiçbir tahmin mükemmel değildir. Erken gelme olasılığı ve geç gelme olasılığı vardır. Boehm'in orijinal ayrıntılı COCOMO modeli, gerçek sonucun% 30'unda olduğu ve zamanın% 60'ından daha iyi olduğu tahminlerini verdi. Bu, kitabı yazıp yayınladığında yaygın olandan çok daha iyiydi.

En iyi tahmininizi yaptığınızda (ve bu bir tahminin hepsidir), bu olasılıkları dahil etmiş olursunuz. Eğer tahminde bulunursanız, geç gelme ihtimalinizi arttırıyorsunuz. Tahmini artırırsanız, erken gelme veya zamanında bitirme olasılığını artırıyorsunuz. Onu ne kadar içeri çektiğinize veya bıraktığınıza göre, olasılığın nasıl değiştiğini kontrol eder ve mutlaka erken veya geç kalma cezalarına bağlı olmalıdır. (Korku hikayelerini buraya ekleyin - ve yıllar boyunca bunlardan bir sürü oldu!)

DeMarco bunu bir dereceye kadar ele alıyor. Ayrıca “imkansızlık bölgesi” olduğuna da dikkat çekiyor: bazı programlar ne tür bir kahramanlık girişiminde bulunulursa yapılsın çok sıkı.