Öncelikle problemi çözmekten oluşan görevler için zamanı nasıl tahmin edebilirsiniz?

Deneyimli bir geliştiricinin, kod çözme modeli ve problemi çözüldüğünde kod uygulamasının ne kadar süreceğini tahmin etmesi nispeten mümkün olmakla birlikte, hedefin ne kadar iyi anlaşıldığı anlaşılırken uygulama% 95 teorik / problem çözme ve çok az miktarda uygulamaya sahip mi?

Çalışmam sıklıkla iyi tanımlanmış hedeflere ulaşmak için yaptığım görevlerden oluşuyor, ancak bu hedefe ulaşmak için bir yol bulmalıyım ve çözümü anlayana kadar, hangi ek engellerin olabileceği belli değil. Daha spesifik olarak, sıklıkla kod oluşturma veya otomatik kod işleme araçları üzerinde çalışıyorum. Çözelti tamamen çözüldüğünde ve alet mükemmelleştiğinde, gerçek değişikliklerin% 95'ini doğrudan çok hızlı bir şekilde yapacaktır. Bununla birlikte, üretim veya analiz aracının öngörülemeyen son durumlarla başa çıkabilmesi için ne kadar ek sorunun çözülmesi gerektiğini tahmin etmenin bir yolu yoktur.

Planlama amacıyla, şirketim ne kadar süreceği konusunda daha iyi bir fikir istiyor, ancak çözümün her adımını çözerek çalışırken kaç tane ek sorun çıkabileceğini bilmediğim için. Daha iyi bir tahminde bulunmaya nasıl yaklaşabileceğimden emin değilim.

Çok uzağa gitmeden önce, Yazılım Tahmininin: Siyah Sanatın Demistleştirilmesi'nin tahminlere bakan ve tahmin eden insanlar için mükemmel bir kaynak olduğunu söyleyeyim . Aşağıdaki resimlerin her ikisi de, eğer aşağıdaki fikirlerin sunulduğu takdirde, özünde olduğu gibi, bu kitaptan alınmıştır.

Sizin de belirttiğiniz gibi, tahminler işi doğru bir şekilde tahmin edebilme ve planlayabilmenin önemli bir parçasıdır. Tahminlere sahip olmamak, işletmeyi bir şeyin ne kadar süreceği konusunda kör yapar. İşletmelerin, işlerin ne kadar süreceği konusunda tamamen yanlış bir fikir edinmesi nadir değildir - kolay düşündükleri altı ila sekiz hafta sürer ve zor olduğu düşünülen bir cuma öğleden sonra kesmek olur.

İlk şey bir tahmin vermektir. Bir tahminin kendisi tek bir sayı değildir - bu bir taahhüttür. "ABC'nin süresi ne kadar sürer" -> "Yaklaşık 5 gün", yaklaşık 5 gün demektir. Ancak, iyi bir tahmin,% 90'ın bu aralıkta olacağına güvendiğiniz bir aralıktır. "% 90'ın 1 ile 5 gün arasında süreceğinden emin olduğumu" demek istiyorsan bunu söyle. "Ben 1 ila 10 gün alacağını düşünüyorum, bu yüzden 5 gün muhtemelen ortalama" olduğunu düşünüyorum - bu bir tahmin değil ve zamanın% 50 yanlış olacak.

Eh, zamanın% 50 veya daha fazlası, programcılar görev süreleri için ünlü küçümseyen insanlardır.

Belirsizlik Konisini düşünün:

^{_{Image http://www.construx.com tam makale - http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

Bu aralıktaki ilk tahminin 16x olduğunu anlayın. Bu, "Sanırım bir öğleden sonra iki hafta alacağını düşünüyorum" demeye benzer - ama henüz bilmiyorsunuz. Tasarımda biraz ilerlerken, aralık 4x'e kadar daralıyor. Bu mu değil evet, tahmin yükseldi, aynı zamanda tahmin aralığı gitti - bu bir hafta sürebilir anlamına, bunun yerine "şuna biraz baktıktan sonra, üç hafta arasında sürer" diyerek olacağını anlamı aşağı.

Verdiğiniz her tahminde, tahminin o aralıkta olduğundan% 90 emin olmanız gerekir. Yanılıyor olabilirsiniz - bu aralığın dışına çıkacak zamanın% 10'u.

Projelerin boyutunu tahmin etmenin birçok yolu vardır . Bunu geçmiş projelerle karşılaştırarak, bir vekil kullanarak (yazmanın bu kadar uzun sürecek olan 1000 satır kod alacağını düşünüyorum), işlev noktalarını kullanarak (LOC'ye dönüştürmek ...), birkaç kişiden tahminler almak ve sonra yinelemeli bir şekilde incelemek ... bazıları bazı projeler için, bazıları diğer projeler için çalışır.

Bir çok ben üst kısmında belirtilen bu kitapta önemli bir bölüm ile ilgilenen # 23 olan siyaset tahmini ve yöneticileri ve yöneticiler ile uğraşan.

Bir tahminin anahtarı, üzerinde çalıştıktan sonra, onu ayrıntılandırmanın yinelemeli sürecidir.

Süreçte çok erken bir tahmin kesinliği verilmesi, hataya açık olabilir. Bundan emin değilseniz, geniş bir tahminde bulunun ve daha sonra soruna daha fazla göz yummak için bir süre sonra tekrar bir tahmin yapın ve daha sonra ne kadar kod yazdığınızı inceleyerek muhtemelen nasıl yapacağınızı açıklayın En son benzer sorun ve tahmini etkileyecek diğer faktörler.

Tahminler biraz düşünmeyi gerektirir - manşet tahminlerini bırakmayın. Bunlar genellikle, biraz düşündüğünüzde aldığı ile karşılaştırıldığında çok büyük hatalarla ilişkilidir.

Gönderen Eğer bir tahmin sorulduğunda cevap nasıl?

Bir Tahmini İstediğinde Ne Demek?

"Sana geri döneceğim" diyorsun.

Süreci yavaşlatırsanız ve bu bölümde anlattığımız adımlardan biraz zaman geçirirseniz, neredeyse her zaman daha iyi sonuçlar alırsınız. Kahve makinesinde verilen tahminler (kahve gibi) size musallat olmak için geri dönecektir.

Yazılım Tahmini Bölüm 4'ten:

Bu konuda, biraz gözden geçirme sonrasında yapılan tahminlerin sistematik olarak daha az vahşi olduğunu ve manşet dışı tahminlerinden daha hataya eğilimli olduğunu unutmayın. Manşet tahminlerini yapma. Oturun ve görev hakkında düşünün ve biraz düşündükten sonra onu tahmin edin.

Patron : AJ, 3 köpek, 2 tavşan, bir mancınık ve bir rahibe var. Köpeklerin hiç tavşanı yemeden ve rahibeyi boğmadan, 7 metrelik bir duvarı geçip diğer taraftaki göle 7 kişiyi (evet, mancınığı) sokmanın bir yolunu bulmalıyız. Çözümün ortaya çıkması ne kadar sürer?

Bakın, bir problemi çözmenin ne kadar süreceğini tahmin eden problem, farklı insanlara farklı bir zaman ayırmasıdır. Benzer sorunları çözme geçmişiniz varsa, sizi daha önce ne kadar sürdüğüne bağlı olarak tahmin edebilirsiniz. Yapmazsan, o zaman tahmin edemezsin, sadece tahmin edersin.

Ayrıca, sorunun kabul edilebilir bir çözümü bile olmayabilir. Veya belki de çözüm, tüm projeyi atabilecek daha fazla yetkilendirme gerektirecektir. Veya belki de çözüm, sorunun tümüyle gereksiz olması için sorunun algılanan yapısını değiştirir.

Hikayenin ahlaki, makul bir tahmin yapmak için yeterli bilgiye sahip değilseniz, o zaman yapmayın . Henüz değil. Daha fazla bilgi edinin. Daha fazla araştırın. Genelde "2 gün içinde size daha katı sayılarla geri döneceğim" demek mükemmeldir.

Müşterim için bir çözüm tasarlarken, çözümün nasıl görüneceğini ve projenin ne kadar süreceğini bilecek kadar genel tasarımın tamamlanmasına kadar sözleşme imzalamam. Bu, (proje geçmezse) parasını alamadığım ilk tasarım işini yapma riskim olduğu anlamına geliyor, ancak bu, yapılan iş için önemli ölçüde düşük faturalandırma riskinden daha iyidir. .

Aşağıdakilerle tylerl ve MichaelT arasındaki cevapların ortasında bir şeyler denemenizi öneriyorum :

• yapılacak işi 3 ya da 4 aşamada bölün. Aşamalar şöyle olmalıdır:
  1. Problem analizi
  2. Çözüm prototipleme
  3. Gerçek dünya çözümü
  4. Çıktı değerlendirmesi (test)
• Yalnızca deneyiminize dayanan 1. Aşama (analiz) için veya yönetiminize 1 + 2 Aşama (analiz + prototip) için bir tahmin yapın. Ardından, 1 ve 2 numaralı problemler tamamlandığında (veya en azından tahmininize güvenebilmeniz için yeterince gelişmiş), 3 + 4.

Bunun arkasındaki mantık, belirli bir kod tabanını analiz etmek için X güne ihtiyacınız olduğunu (muhtemelen boyutuna bağlı olarak) ve çalışan temel araçların veya komut dosyalarının bir takımının (ve belki de başarısızlığın) olduğunu bilmenizdir. Daha sonra, hataların sayısı eldeki görevin asıl zorluğu hakkında size bazı bilgiler sağlamalıdır.

Bu tam olarak yönetimin istediği şey olmayabilir, ancak gerçekten tanışacağınız tahminleri ortaya koymak her zaman daha iyi olduğuna inanıyorum.

Bu soru öncelikle araştırma türleri ile ilgili olduğu için, yazılım geliştiricilere sormak cesur bir yaklaşımdır, ortak bir ölçüm, tahminleri muhtemelen iyi bir geliştirici olduğu sürece iki kez süren bir yazılım geliştiricisidir. Bununla birlikte, araştırma (ve mimarlık tasarımı) görevleri programlamanın bir parçasıdır ve çoğu zaman atlanır / küçültülür. Ayrıca tahmin etmek genellikle zordur.

Kendime soracağım ilk soru, çözülebilecek bir problem mi? Bu bir akıl veya beyin gücü sorunu değil, pratik gerçeklerden biridir. Eğer başarısızlık beklenen bir sonuçtur Google ay çekimleri, dünyada olduğu sürece, sert gerçeklik ben vermesi bekleniyor olacağıdır bu her neyse, bu çıkıyor. Sert bir kural gibi görünüyor ki, çözümün% 90'ının ne olması gerektiğini zaten biliyor muyuz?

Sormam gereken ikinci soru , çözüm hakkında düşünmek için başka ne bilmek yararlı olacaktır? Bu gerçekten çift kontrol yapmanın bir yolu, gerçekten de kabul edilebilir bir çözüm bulmak için yeterince bilgimiz var. Çözümün ne olması gerektiğini daha iyi tanımlamaya yardımcı olan ve her biri tanımlaması ve tahmin etmesi genellikle kolay olan bir dizi gerçek bulma görevi oluşturabilir.

Üçüncü soru, bu tür bir sorun için ekipte en uygun kim? Bu görevi kim alırsa sonucu kendi tarzına göre tadacaktır. Bu tür bir problemi bir görevin başlangıcında 10 milyon sorusu olan bir programcıya vermek, sonra da uzağa gider ve ilk kez bir şey sunar (yavaşça da olsa) çabuk bir şekilde uygulamadan çıkan programcıya vermekten daha iyi bir seçim olabilir. , ama bir sorun olduğunda, sadece sürecin sonunda keşfedildi.

O zaman asıl görev , olası çözümler, uygulamalar ve yaklaşımlar hakkında düşünmek ve geri bildirimde bulunmaları gereken sabit bir zaman ölçeğine sahip olmaktı.

Geri bildirimde bulunduklarında, çözüm hala yeterince açık bir şekilde tanımlanmadığından, daha geniş bir olası çözüm kümesi alma, çözüm uygulamaya devam etme veya yansıtma konusunda bir seçeneğiniz vardır.

Bir cevabın tam olarak bulunmadığının açık olmadığı araştırma soruları ile, yapılması gerekenler konusunda net bir fikir bile olsa, genellikle başlangıçta x zamanını harcamayı öneriyorum.

“Bu mümkün olsa bile hiçbir fikrim yok, ancak iki gün boyunca onu araştırmaya harcayabilirim. Bu muhtemelen bize bir çözüm getirmeyebilir, ama belki bazı şeyleri ekarte edebilirim ve muhtemelen bir fikrim olur. Bundan sonraki somut adımların neler olabileceği ve ne tür bir zaman yatırımı anlamına geleceği. O zaman başka bir adım atmanın mantıklı olup olmadığına karar verebiliriz. ”

Öyleyse belirsizliği diğer yöne koyun - tahmin güzel bir şekilde kesin (iki gün geçireceğim), o zamana kadar ne elde edileceği henüz çok belirsiz.

Temel olarak Timeboxing.