it-swarm.asia

Tahmin istendiğinde nasıl yanıt verilir?

Programcı olarak bizlere sürekli olarak 'Ne kadar sürecek' soruluyor.

Ve biliyorsunuz, durum neredeyse her zaman böyle:

  • Gereksinimler belli değil. Kimse tüm çıkarımların derinlemesine bir analizini yapmamıştır.
  • Yeni özellik muhtemelen kodunuzda yaptığınız bazı varsayımları kıracak ve yeniden düzenlemeniz gerekebilecek her şeyi hemen düşünmeye başlayacaksınız.
  • Geçmiş ödevlerden yapacak başka şeyleriniz var ve bu diğer işi dikkate alan bir tahmin bulmanız gerekecek.
  • 'Done' tanımı muhtemelen belirsizdir: Ne zaman yapılacak? Kodlamayı bitirmiş gibi 'Bitti' mi yoksa “kullanıcılar kullanıyor” da olduğu gibi 'bitti' mi?
  • Tüm bu şeyler hakkında ne kadar bilinçli olursanız olun, bazen "programcısının gururu" sizi başlangıçta alabileceğinizden daha kısa süre verir/kabul eder. Özellikle son teslim tarihlerinin ve yönetim beklentilerinin baskısını hissettiğinizde.

Bunların birçoğu basit ve çözülmesi kolay olmayan örgütsel veya kültürel konulardır, ancak sonuçta gerçek şu ki, bir tahmin isteniyor ve makul bir cevap vermenizi bekliyorlar. Bu işinizin bir parçası. Basitçe söyleyemezsin: Bilmiyorum.

Sonuç olarak, her zaman daha sonra yerine getiremeyeceğimi fark ettiğim tahminleri veririm. Birçok kez oldu ve her zaman tekrar olmayacağına söz veriyorum. Ama öyle.

Bir tahmine karar verme ve sunma konusundaki kişisel süreciniz nedir? Hangi teknikleri yararlı buldunuz?

665
Sergio Acosta

Pragmatik Programcı: Journeyman'dan Master'a :

Bir Tahmin İstendiğinde Söylenecekler

"Sana geri döneceğim" diyorsun.

İşlemi yavaşlatırsanız ve bu bölümde açıkladığımız adımlardan geçerek biraz zaman harcarsanız, neredeyse her zaman daha iyi sonuçlar alırsınız. Kahve makinesinde verilen tahminler (kahve gibi) size musallat olmak üzere geri gelecektir.

Bu bölümde yazarlar aşağıdaki işlemleri önermektedir:

  • İhtiyacınız olan doğruluğu belirleyin. Süreye bağlı olarak, tahmini farklı hassasiyette teklif edebilirsiniz. "5-6 ay" demek, "150 gün" demekten farklıdır. 7. aya biraz kayarsanız, yine de oldukça hassassınız. Ama 180. veya 210. güne girerseniz, çok fazla değil.
  • Ne sorulduğunu anladığınızdan emin olun. Sorunun kapsamını belirleyin.
  • Sistemi modelleyin. Bir model zihinsel bir model, diyagramlar veya mevcut veri kayıtları olabilir. Bu modeli ayrıştırın ve bileşenlerden tahminler oluşturun. Her bir değere değerler ve hata aralıkları (+/-) atayın.
  • Tahmini modelinize göre hesaplayın.
  • Tahminlerinizi takip edin. Tahmin ettiğiniz sorun, tahmininiz ve gerçek değerler hakkındaki bilgileri kaydedin.
  • Tahmininize dahil edilecek diğer şeyler, gereksinimleri veya gereksinimler spesifikasyonlarındaki değişiklikleri geliştirmek ve belgelemek, tasarım belgeleri ve spesifikasyonları oluşturmak veya güncellemek, test etmek (birim, entegrasyon ve kabul), değişikliklerle birlikte kullanıcı kılavuzları veya README'ler oluşturmak veya güncellemektir. Birlikte çalışan 2 veya daha fazla kişi varsa, ek yük (telefon görüşmeleri, e-postalar, toplantılar) ve birleştirme kaynak kodu vardır. Uzun bir görevse, bir teslim tarihi seçerken diğer iş, tatil (tatil, tatil, hastalık zamanı), toplantılar ve diğer genel gider görevleri gibi şeyleri dikkate alın.
395
Thomas Owens

Yazılım tahmini, yazılım mühendisliğindeki en zor tek görevdir - yakın bir saniye de ihtiyaçların ortaya çıkarılmasıdır.

Bunları oluşturmak için bir sürü taktik var, hepsi önce iyi gereksinimleri elde etmeye dayanıyor. Ama sırtınız duvara yaslandığında ve size daha iyi detaylar vermeyi reddettiklerinde, Sahte O:

  1. Sahip olduğunuz gereksinimlere bir göz atın.
  2. Ne istediklerine dair en iyi tahmininize dayanarak boşlukları doldurmak için varsayımlar yapın
  3. all varsayımlarınızı yazın
  4. Onları oturtun, okuyun ve varsayımlarınızı kabul edin (veya eğer şanslıysanız, onları vermelerini ve size gerçek gereksinimleri vermelerini sağlayın).
  5. Artık tahmin edebileceğiniz ayrıntılı gereksinimleriniz var.

Annem çocukken tehdit ediyormuş gibi "Çabuk ol ve biraz kıyafet seç, ya da I onları senin için seç!"

172
Fishtoaster

Doğru tahminler istemek konusunda çok kararlı bir adam için gelişim yaptım. Yerleştirdiğimiz, çok iyi çalışan şey şuydu:

  • Tahmin etmek için harcadığım süre boyunca faturalandırdım. Faturalandırdıklarımın yaklaşık% 20-25'ine geldi.
  • Görevleri son derece detaylı inceledim. Kalçadan ateş yok. Kodun içine girdim, hangi satırların değiştirilmesi gerektiğini, programın diğer bölümlerini etkileyeceğini, işlerin hala çalıştığından emin olmak için ne kadar test yapmam gerektiğini anladım. Her parçayı .1 saat (6 dakika) cinsinden tahmin ederim.
  • Ona her görev için tahminimi ve ayrıntılı dökümü gönderdim.

Faturalandırmanın% 20-25'i çok gibi geliyor.

Ama benden yaklaşık 2 saat süreceğini düşünerek XYZ'de değişiklik yapmamı isterdi. 1 saatlik ayrıntılı tahminde 8,5 saat alacağını belirleyeceğim. Bu yüzden 8,5 saatlik ödemeye değip değmeyeceğine karar verecekti. Değilse, tahmin etmeden yapsaydım, ne kadara mal olacağından 7.5 saat tasarruf etti.

Ve eğer yaptı 8.5 saate yatırım yapmak istiyorsa, tahmin için yaptığım detay işi zaten yapmak zorunda olduğum işti.

Bu yöntemle, çoğu görevi çok fazla abartmak zorunda kalmadan zamanında veya hatta erken getirebildiğimi buldum. Zaman çok küçük bir şekilde parçalandığından, kayıp kaymadığımı erken söyleyebilirim. 3 saat sonra 8.5 saatlik görevimin 12 alacağını söyleyebilseydim, daha fazla zaman geçmeden onunla konuşabilirdim, böylece maliyet hakkında endişeliyse özelliği yeniden değerlendirebilir ve çekebilirdi. .

Nikel ve dimer miydi? Hayır, ona parasını en çok yarar gördüğü yere uygulamasına izin vererek baktım. Ve her zaman korkunç olduğum tahminlerde deneyim kazandığım için çok mutluyum.

145
Kyralessa

Bize ne yapmak istediklerine dair çok geniş ve kesin fikirler verildiği toplantılarda sık sık bir "basketbol sahası tahmini" istenir. Ben her zaman diyorum ki, "bugün bir cevap istiyorsan bir yıl ve bir milyon dolar. Bana çok daha fazla ayrıntı vermek ve bunları gözden geçirmek için biraz zaman vermek istiyorsan, o rakamları senin için düzeltebilirim."

Neredeyse her zaman bunu anlıyorlar.

65
Walter

Bu tahminin ne olduğuna bağlıdır.

Bir iş vakası için ilk, yüksek düzeyli bir tahmin için, temel şeyler şunlardır:

  1. Hız. Hangi yöntemi kullanırsanız kullanın hızlı olmalıdır. Bütün mesele, paydaşların projeyi yapmaya değip değmeyeceğinden emin olmamalarıdır - bu yüzden iş vakası için sayılara ihtiyaç duyuyorlar. İş vakası sağlam olsaydı tahminlerinize ihtiyaç duymazlardı. Bu projelerin büyük kısmı devam etmeyeceğinden, tahmin sağlamak için çok fazla çaba harcanmaması önemlidir.
  2. Menzil verin. Genişletin. Gereksinimleri analiz etmek, paydaşlarla çalışmak, varsayımları doğrulamak için zamanınız yoktu. Geniş bir yelpazede, alıcıya "Yazılım projeleri doğal olarak karmaşık ve riskli - doğru bir tahmin istiyorsanız bana daha fazla ayrıntı ve daha fazla zaman vermeniz gerekiyor" tahminini veriyor. Tek bir sayı veya dar bir aralık vermenin sorunu, herhangi bir gerçek analiz yapılmadan önce beklentileri belirleyerek sizi köşeye boyamasıdır.

Ben de aynı şeyi hisseden karşılaştırılabilir bir proje seçmek için en iyi tekniği buluyorum. "Hissedin" tamamen özneldir - ancak bu tür bir tahminle deneyimlerim bana objektif ölçümler bulamayacağınızı söylüyor. Sonra geniş bir aralık sağlayın. % -50 ila +% 100 aralığının iyi olduğunu söyleyen bazı kitaplar okudum ama birçok faktöre bağlı.

Ayrıntılı, düşük seviyeli bir tahmin için:

  1. Bir taban çizgisine ihtiyacınız var. Taban çizgisi sabit değilse tahmin anlamsızdır.
  2. Aşağıdan yukarıya en iyisi. Ayrıntılı bir iş dökümü alın, her bir bileşeni tahmin edin ve ardından daha büyük bir sayıya yuvarlayın. Planlama pokerinin burada harika bir teknik olduğunu düşünüyorum.
  3. Belge beklenmedik durumu. Herhangi bir beklenmedik durumun (varsa) nereye eklendiğini netleştirin. Her satır öğesine eklenmiş mi? Yoksa tüm tahmine mi? Veya belirli risklere mi? Yoksa hiç yok mu?
  4. Varsayımlarınızı belirtin. Zaman dilimi göz önüne alındığında mümkün olduğunca çok onaylayın.
  5. Tahmine neyin dahil edilip neyin hariç tutulduğunu açıkça belirtin. Örneğin, inceleme dahil mi? Teknik gecikmeler var mı?
55
darreljnz

Karanlık yoldan zor yolu öğrenenlerden bazı tavsiyeler.

Gereksinimler belli değil. Kimse tüm çıkarımların derinlemesine bir analizini yapmamıştır.

Bu noktada bir tahmin yapmayın. Düşman sayıları hakkında hiçbir ipucu olmadan bir savaşı kazanmak için kaç askere ihtiyaç olduğu tahmin edilmez. Tahmin izcilikten sonra yapılır. Bu düşmanla savaşmadığınız sürece budur.

Yeni özellik muhtemelen kodunuzda yaptığınız bazı varsayımları kıracak ve yeniden düzenlemeniz gerekebilecek her şeyi hemen düşünmeye başlayacaksınız.

Başkalarının bu alanla ilgili uzmanlığa sahip olmasını beklemediğiniz sürece, bu faktör dikkate alma sorumluluğunuzdur.

Geçmiş ödevlerden yapacak başka şeyleriniz var ve bu diğer işi dikkate alan bir tahmin bulmanız gerekecek.

Yukarıdaki ile aynı, yanınızda bir slob takım arkadaşı tarafından yaratılan beklenmedik çalışmalar için bile, kodunuzun önceden tahmin edemeyeceğiniz şekilde hata vermesine neden olan neredeyse yok olan bir test prosedürüyle. Hava tahmini.

'Done' tanımı muhtemelen belirsizdir: Ne zaman yapılacak? Kodlamayı bitirmiş gibi 'Bitti' mi yoksa “kullanıcılar kullanıyor” da olduğu gibi 'bitti' mi?

Buradaki kullanıcı sonu gereksinimini anlayın, bir kullanıcı gibi düşünün. Eğer hiçbir kullanıcının muhtemelen tolere edemeyeceği bir barebone iş akışına sahip bazı temel işlevlerin "done" olduğunu düşündükleri şey olduğu için, akranlarınızın "yapılması gereken" bir şey olduğunu tahmin ederse yaptıklarını yapmayın. Bunu kullanıcı açısından düşünün, çünkü tahmin ettiğiniz tüm müşteri genellikle anlayacaktır. Barebone teknik gereksinimlerine değil, tam kullanıcı sonu gereksinimlerine yönelik tahmin. Ve tahminler isteyen müşterilerinizin, şeyleri nasıl ifade ettikleri ve söylediklerinizin teknik yönlerini anlamaları konusunda burada tamamen yanlış olacağını anlayın.

Tüm bu şeyler hakkında ne kadar bilinçli olursanız olun, bazen "programcısının gururu" sizi başlangıçta alabileceğinizden daha kısa süre verir/kabul eder. Özellikle son teslim tarihlerinin ve yönetim beklentilerinin baskısını hissettiğinizde.

Bunu yapma! Kendini motive eden ve muhtemelen zorla kolayca teslim olan bir işçi gibi konuşuyorsun.

Buradaki sorun şudur: Diyelim ki siz ve Joe aynı görev için zaman tahminleri yaptınız (ancak iki ayrı çalışan arasında, her iki tahminin de bir seferde farkında olmadığını). Cesurca tahmin edersiniz, "bir hafta". Haftada 100 saatten fazla çalışacaksınız, ücretsiz fazla mesai olduğunu düşünebilirsiniz. Şimdi üç gün geç kaldın.

Bu arada Joe 5 ay tahmin ediyor. Bunun gülünç olduğunu düşünüyorsun, bunu bir hafta içinde çekebileceğini düşünüyorsun. Joe ne kadar çalışıyor? Haftada 10 saat? ... tam olarak 5 ayda bitirmesi dışında.

Tahmin edin kim jackass olarak algılanıyor? Bu doğru, sen. Joe harika bir işçi gibi görünüyor, şimdi güvenilmez görünüyorsun. O kadar önemli değil ki Joe'nun aldığı sürenin ~% 7'sinde daha iyi bir sonuç elde etmiş olabilirsiniz. Önemli olan bir haftalık tahminden 3 gün izinli olmanız.

Asla daha sıkı tahminin yanında hata yapmayın. Daha gevşek tahmin tarafında Err. Şirketinizde inşa edeceğiniz bir itibar var ve tahminlerinizin uzunluğuna, tahminlerinizin doğruluğu kadar dayanmayacak. Çok uzun bir tahminle doğru olmak kolaydır, sorun üzerinde çalışmak ve daha iyi çözmek için daha fazla zaman alırsınız. Çok kısa bir tahmin, hiç nefes alma alanı bırakmaz, ya umutsuzca karşılarsınız ya da vidalanırsınız.

28
user204677

"İki hafta!"

Ciddi anlamda. İlk tahminim her zaman iki haftadır. Çünkü tuhaf bir zihinsel bloğum var, bu da bana her şeyin iki hafta gibi geleceğini düşündürüyor.

Etrafında çalışmaya çalışıyorum, gerçekten düşünmek Bir şeyin ne kadar süreceğini düşündüğüm hakkında, doğru tahmin edemeyeceğim kadar kara kutu-y gibi görünen tüm potansiyel sorunlu noktaları ve bitleri belirlemeye çalışıyorum. Ve cevabım "İki hafta!" İse, bunu yapamadığımı anlamaya çalışın.

Hemen hemen her iyi yönetici "İki hafta!" cevap olarak hafif bir sözel pezevenk tokat gerektiren bir cevap olarak.

18
BlairHippo

Önceki tahminlerinizin ne kadar doğru gittiğini nasıl kaydedeceğinizi özetleyen bir blog girişi vardır ve daha sonra birisine "iki hafta olacak" dediğinizde, önceki tarih ve "iki hafta olacak" dediğin son seferde ne kadar sürdüğünü görün.

Kendim denemedim, ama tahminlerimin ne kadar doğru olduğunu görmek istiyorum.

17
Richard

Kuruluşa ve tahminlerin nasıl kullanıldığına bağlıdır.

Eğer tahmin sadece ne zaman hazır olacağına dair genel bir fikir vermekse, genellikle tecrübelerime dayanarak hızlı bir tahmin yapabilirim. Çoğu zaman, değişikliklerin sistemin diğer alanlarını nasıl etkileyebileceği ve gerekli regresyon testinin kapsamı ile birlikte tahminle ilgili herhangi bir belirsizlik veya olası varyasyon içereceğim.

Tahmin, sözleşmeye bağlı herhangi bir şey için veya daha kesin zamanlamanın gerekli olduğu bir senaryoda kullanılıyorsa, tam bir iş kesintisi yaparım. Bu daha fazla iştir ve tasarım ve sistemdeki değişiklikler hakkında daha fazla düşünmeyi gerektirir, ancak özellikle daha büyük iş parçaları için çok daha doğrudur.

Her iki durumda da, devam eden iletişim önemlidir. Beklenmedik bir şeyle karşılaşırsanız, son tarihe kadar beklemek yerine o anda bilinmesini sağlayın. Gereksinimler açık değilse, bunları anladığınızı ve sunmayı planladığınız işlevselliği belgelediğinizden emin olun. Bu, yaptığınız varsayımlarda da yardımcı olur. Ve rakip öncelikler, bir iş parçası diğerini çarptığında, bunun programı nasıl etkileyeceği konusunda net olun.

11
g .

Ne için tahmin? Küçük görevler veya komple çözümler.

Ikincisi nadiren yapıyorum ama sonra sadece tahmin, biraz ekleyin, müdür biraz ekleyin ve yukarıdaki bir tahmin olduğunu belirten küçük bir not ile bir aralık içine yapmak var.

Küçük görevler - Planlama pokeri Gerçekten iyi çalıştığını buldum (mükemmel değil, bazı 1pt görevleri çok daha uzun sürdü ve bazı 5pt görevleri dakikalar aldı, ancak sonunda sonuçta ortaya çıkıyor).

9
mlk

Bugün bildiklerinizi temel alan bir aralık sunun. İlk tahminlerinizin etrafındaki aralığı sağlamak için Belirsizlik Konisi kullanın.

Her hafta ne kadar kalacağınızı hesaplayın, bildiklerinize göre yeniden tahmin edin. Her hafta ne kadar iş yaptığınıza dair yeterli bir örneklem büyüklüğüne sahip olduğunuzda, proje ilerledikçe ve kalan iş miktarı (umarım ) küçülür.

7
Paddyslacker

Kendine güvenerek. Tahmin verirken profesyonellik yapmayarak bir müşteriyle ilk toplantıyı kaç kez başlattığımı söyleyemem. Rakamları ince havadan temizliyor olsanız bile - her zaman tahminlerde bulunduğunuzdan emin olun. Bununla birlikte, kendinizi bir deliğe tahmin etmemeye dikkat edin. Farklı şeyler bir araya getirmek için farklı miktarda zaman, çaba ve kaynak gerektirir. İşte bunu yapmanın iyi bir yolu:

Onları: Ne kadara mal olacak?

Ben: Ne yapmamı istediğine bağlı. Genellikle, bu tür bir projeye yaklaşık X $ 'dan başlarım.

7
Moshe

Bazen tahmin, özellikle yazılım projesi tahmini hakkında konuşurken, sizin ve ekibiniz için büyük bir zorluk haline gelir.

Deneyimimizi ve yazılım tahmin süreci hakkındaki bilgilerimizi paylaşmaya karar verdikten ve dört farklı tahmin türü :

  • basketbol sahası figürü
  • hizmet tahmini
  • özellik tahmini
  • bileşen tahmini

Tabii ki, bu türler farklıdır. Ballpark, genellikle “guesstimate” olarak adlandırılır. Bu, genel bir maliyet fikri veren ve bir potansiyel müşterinin tartışmayı daha ileri götürmek isteyip istemediğine karar vermesine yardımcı olabilecek yaklaşık bir sayı veya aralıktır.

Kural olarak, müşteriler projenin başında bir ballpark figürüne ihtiyaç duyarlar. Ve tavsiyemiz: projenin tartışılması ve basketbol sahası figürlerinin sağlanması, sadece bileşen tahmini (esnek olan, Tüm geliştirme süreci için bileşen türü tahmini.Özellikler, hizmetler vb. eklemek, kaldırmak veya değiştirmek istediğinizde sıfırdan yeniden tahmin etmeye gerek yoktur).

Herkes yazılım geliştirme tahminiyle gelen riskleri akılda tutmalıdır: hafife alma, fazla tahmin etme, toplam destansı başarısızlık senaryosu vb.

Blogumuzda daha fazlasını okuyabilirsiniz!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Umarım bu bilgi size yardımcı olur!

6
Olha

Her zaman daha sonra yerine getiremeyeceğimin farkına varacağım tahminler veririm. Birçok kez oldu ve her zaman tekrar olmayacağına söz veriyorum.

Bir tahmin değil, bir taahhüt isteniyor gibi görünüyor. Bunlar farklı şeylerdir, ancak taahhütleri güvenilir bir şekilde yönetebilirseniz, güvenilirliğinize ve kariyerinize gerçekten yardımcı olacaktır.

~ 10 yıllık deneyimime dayanan bazı tavsiyeler:

  • Her zaman bir aralık sağlayın (yani alt ve üst sınır). Bu, belirsizlik seviyenizi iletir
  • Çok büyük bir belirsizliğiniz varsa erteleme isteyin (örneğin analiz yapmak için 1 gün ve daha sıkı bir aralık sağlayın)
  • Görev çok büyükse, parçalayın ve her parça için bir aralık sağlayın
5
jamesfmackenzie

İlk olarak, eğer bana bir görev atandıysa alt görevlere ayırırdım, her alt görev için zamanı tahmin ederdim ve muhtemelen alt görevlerle sorunlu alanı bulabilirim ve bu yüzden ne kadar süre olacağını tahmin edebilirim bir dereceye kadar almak.

Ancak yine de tüm planlama sadece belirli bir dereceye kadar yardımcı olacaktır. Yalnızca kodlamaya başladığınızda kesin sorunları bulabilirsiniz

4
Gopi

Aynı patron veya müşteri için birçok proje yaparsanız, haftalar veya aylar yerine, muhtemelen t-shirt boyutlarında geniş karmaşıklık darbeleriyle tahmin etmeye çalışabilirsiniz. Geçmiş birkaç projeyi belirleyin ve onlara S, M, L, XL boyutlarını atayın.

Ve sonra kendinize sorun: Bu, hangi projenin kapsamına benziyor? Ve sonra "2 Ay" ile cevap vermek yerine, "bana bir L gibi geliyor" (veya proje için kalibrasyonunuz ne olursa olsun) ile cevap verebilirsiniz.

Bunu anlamak oldukça kolaydır ve bu tahminlerde çok fazla belirsizlik olduğu da açıktır.

Ardından, gereksinimler değiştiğinde, "bu değişiklik bir XL gibi ses çıkarır" diyebilirsiniz.

1
moritz

Biraz geç ama ordudayken tahminleri belirlemek için PERT kullanmamız istendi. Alanınızda ve mevcut görevinizde biraz deneyim gerektirir. Rutin bakım sırasında çok sayıda şeyin yanlış olabileceği veya bulunabileceği ve düzeltilmesi gereken elektronik cihazları (karmaşık telsizler ve uydu iletişim ekipmanları) korurken ve tamir ederken tahmini tamamlanma süresini belirlerken şaşırtıcı derecede doğruydu. Tahminler önemliydi, çünkü diğer birimler haberleşme teçhizatını geri alana kadar çalışmaz olabilir. Kullandığım şey bu Ücretsiz Çevrimiçi PERT Hesaplayıcı

0
xtreampb