Programlama görevlerini tahmin etmek için ne kadar zaman harcanır?

Örneğin, bir projeyi n ayrı iş ürününe (dersler veya fonksiyonlar veya bileşenler diyelim) ayırırsam, n * t'nin kestirim için harcamak için uygun bir süre olacağı bir zaman t olur mu?

Bu seviyeye indirecek kadar bilginiz varsa, her birine bir dakikadan fazla harcamamalısınız. Yine de doğru olmayacaksın, ama bir dakika sonra bir saat sonra doğru olacaksın.

Öte yandan, kullanıcı hikayelerinden bahsediyorsan , paydaşları bir odaya koymayı ve tahmin etmeden önce beş dakika soru sormayı öneririm.

Ne olursa olsun, tahminler yapmak için fazla zaman kaybetmeyin. Çabaya değecek kadar kullanışlı veya doğru değiller.

Benim tecrübelerime göre, 'evet, gerçekten işe yarayan' çekirdeklerden biri çevik bir yaklaşımın 'Görevler bir günden az sürmeli' kılavuzudur. Bir günden uzun süren şeyleri tahmin ediyorsanız, oldukça uzakta olacaksınız.

Onları parçaladıktan sonra bunu yapabilmek için yeterince şey yaptın; bu şeylerin ne olduğuna bakılmaksızın.

Çevik scrum metodolojisinde Planning Poker , bir sprint'teki kullanıcı hikayeleri için gereken çabayı hızlı bir şekilde tahmin etmek için tüm ekibi kullanmanın etkili bir yolu olarak görülür (bunun sizin bahsettiğiniz şey olduğunu varsayarak). Aksi takdirde, bir kullanıcı hikayesinin bir parçası olan tek bir görevi tahmin etmek için birkaç dakikadan fazla zaman harcamazdım.

Bir geliştirici ekibi için tahmin yapmaya çalışıyorsanız, bu fikir birliğine dayalı tekniği kullanmanızı şiddetle tavsiye ederim.

Poker planlamak, tek bir oturumda (1-2 saatten fazla olmamak kaydıyla) her bir kullanıcı hikayesi için oldukça iyi tahminler alabileceğiniz anlamına gelir.

Bu konuda biraz okuma yapın ve bir deneyin!

Ayrıca, genel bir kural olarak, bir kullanıcı hikayesindeki hiçbir görev 7,5 saati geçmemelidir (tek bir günlük çalışma). Varsa, görevi daha küçük görevlere bölmeniz gerekir.

Sanırım neye ihtiyacınız olduğuna bağlı. Örneğin, projenizin kaynak tahsisi buna bağlıysa (bazen burada olduğu gibi), dikkatli bir şekilde yapmak daha iyidir. Diğer bir deyişle, bu tür bir zorunluluk olmayan bir proje yapıyorsanız, çok fazla ayrıntıya giremeyebilirsiniz. Üzerinde çok fazla zaman harcamak iyi bir fikir değil çünkü doğru bir tahmin yapmak çok zor.

Denilen ünlü bir kavram yoktur Belirsizliğin Koni ve Wikipedia'da Belirsizliğin Koni doğru bir tahmin genellikle olabilir ne kadar diyor. Hakkında okumaya değer.

Tahminlerinizden ne elde ediyorsunuz?

Ne üzerinde çalıştığınıza bağlı olarak, doğru bireysel tahminler alakalı olabilir (müşteri hafta sonunda size ödeme yapıyor veya görev / hikaye başkalarına engel oluyor ve kesin bir ETA gerekli) veya değil (birikmiş iş yerinizde 200 öykünüz var, bir hikaye bir hafta boyunca kayarsa kimse ölmeyecek ve çok sayıda kişi için ortalamaları tahmin etmek için tahmini hatalara güveniyorsunuz).

İhtiyaçlarınız için yeterince iyi bir tahmin elde etmek için minimum süreyi harcayın. Formül yok.

Şahsen, bir veya iki dakikadan fazla düşünüyoruz, muhtemelen yanlış şeyi tahmin ettiğiniz anlamına gelir (bölün veya keşif planlayın).

Aslında, diğer paydaşların göreceli öncelik atamasına yardımcı olmak için tahminlere ihtiyacınız vardır - bu nedenle geniş tabanlı tahminler, görev1'in görev2 ile karşılaştırıldığında kabaca 3 kat çaba olduğunu söyler, (saat cinsinden sonunda çok doğru olmasa bile) faydalıdır. Bu görevlerin ne olduğunu (belirli hedeflere ulaşmak için) anlamak ve daha sonra onlar için kaba tahminler yapmak için çok zaman harcamak gerekir.

Göreli önceliğe sahip olduğunuzda, bir şeyler yapmaya odaklanın ve tahminleri rota üzerinde ayarlayın. Başka bir deyişle, ön tahminlerde çok az zaman harcayın, ancak zaman geçtikçe tahminlerinizi hassaslaştırın, böylece proje planı ne yapılacaksa iyi bir fikir verir.

İyi tahminler bir zamanlar varsayımlara değil gerçeklere dayandırılır.

Bu nedenle, zaten benzer bir projeniz / projeleriniz varsa ve önceki tahmin sürenizi yakaladıysanız, bu başlangıç için iyi bir tahmin tabanı olabilir . Bununla birlikte, proje kapsamınıza bağlı olarak, bilinmeyen eserler olabilir , bu da BA veya ürün sahibi ile en kısa sürede netleştirmek için daha iyidir.

Ayrıca şunu söylemek doğrudur: Yazılım Proje Tahmini Doğasında Yanlış . Bununla birlikte, yardımcı olabilecek bazı gerçekçi tahmin uygulamaları vardır:

• İşi yapan insanlar proje tahminine katılmalıdır
• Uzmanları getirin: Uzman kararı proje başarısı için kritik öneme sahiptir
• Büyük parçaları aralık olarak tahmin edin
• Delphi Tekniğini Kullanın : Bu, yazılım projesi tahmininde bir çelişki olması durumunda ekibin görüşlerini birleştirmeye yardımcı olan bir yöntemdir.
• Maliyeti unutmayın
• Çalışmayı gerçekleştirmek için tahsis edilmiş kaynakları unutmayın