Daha önce deneyimim olmayan üçüncü taraf kontrollerini kullanan programlama görevleri hakkında tahminler isteyen yönetimle zor zamanlar geçiriyorum.
Neden tahminleri isteyeceklerini kesinlikle anlıyorum, ancak vereceğim herhangi bir tahmin ya a) çok kısa olacak ve beni kötü gösterecek ya da b) çok uzun ve beni kötü gösterecekmiş gibi hissediyorum.
Yönetime, işimi yapmaya devam edebilmem için onları sırtımdan çekmesi için ne tür bir tahmin veya cevap verebilirim!
Yanıtlar:
Verebileceğiniz en iyi cevap, daha doğru bir tahminde bulunmanıza izin vermek için hızlı bir prototip hazırlayabilmek için zaman istemektir. Bir araç veya problemle ilgili biraz deneyim olmadan , verdiğiniz herhangi bir tahmin aslında anlamsızdır.
Bir kenara, çok uzun bir tahmin vermede çok nadiren sorun vardır. Beklenmeyen sorunlar ortaya çıkar, öncelikler değişir ve gereksinimler "güncellenir". İstediğiniz zamanı kullanmasanız bile, daha fazla test süresine sahip olacaksınız veya "erken" yayınlayabilirsiniz.
Tahminlerim konusunda her zaman çok iyimser davrandım ve özellikle patronlara rahatsız edici gerçekleri söyleyebilecek deneyime ve özgüvene sahip olmayan genç bir programcı olduğunuzda hayatınıza çok fazla stres katabilir.
Sana bir sır vereceğim. Bu teknolojide bir uzman olsanız bile, tahmininiz muhtemelen oldukça yanlış olacaktır. Doğası gereği bir Ar-Ge görevi olan bir şeyi yaparken canavarın doğasıdır. Ne yazık ki yönetim genellikle bir üretim modeli uygulamaya çalışır ve doğru tahminler talep eder. Demek istediğimi açıklamak için, aşağıdaki iki çabayı doğru bir şekilde tahmin etmenin zorluğunu düşünün:
A) Geçen ay ürettiğiniz 2K ile tamamen aynı olan başka bir 11K şemsiye üretin. B) Yeni bir şemsiye türü tasarlayın ve ilkini inşa edin.
Yazılım geliştirme B'dir, ancak A varsayarak bir tahmin istiyorlar.
Yapabileceğiniz en iyi şey, görevi mümkün olan en küçük parçalara ayırmak (her biri en fazla 1/2 gün) ve sonra bulduğunuz son sayıyı üçe katlamaktır. (Spolsky Yöntemi)
Alternatif olarak, Steve McConnell'in yazılım mühendisliğinin bu yönü üzerine bir kitabı (muhtemelen birkaç tane) var. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
Steve McConnell (ve diğerleri) belirsizlik konisinden bahsediyor . Temel olarak şuna benzeyen bir tahmin sağlarsınız:
Çalışma 3 ila 9 hafta sürecek ve en olası 4 hafta olacak.
Proje ilerledikçe tahmininizi hassaslaştırabilirsiniz. Daha fazla iş yaptıkça ve gereken çabayı daha iyi anladıkça tahmininizi daha doğru olacak şekilde düzeltebilirsiniz.
Benim için işe yaradı, ancak süreci anlamak için projedeki diğer paydaşları toplamak biraz çaba gerektirebilir.
Hem bir tahmin hem de bir güven düzeyi vermeyi düşünebilirsiniz, yani 3-6 ay veya 6-9 ay sürecek 50/50 veya 9 ayda% 75 ve% 90 olacaksınız bir yılda yapılır.
Düşünmek isteyebileceğiniz başka bir şey de " kalabalıkların bilgeliği " yaklaşımını kullanmaktır. Etrafta dolaşın ve 25-50 kişiye bunun ne kadar süreceğini düşündüklerini sorun ve tahminlerinin ortalamasını alın. Mike Cohn'un Planlama Pokeri bence buna çok benziyor, ancak tek bir geliştiriciyle planlaması zor.
Tahmininizi aşağıdaki bölümlere ayırın:
Yol boyunca tahmini ve belirli kilometre taşlarını ayarlamayı önerin. Bilinmeyen bilinmeyenler, bilinen bilinmeyenler haline gelecektir, siz deneyim kazandıkça bilinen bilinmeyenler bilinmelidir ve bilinen bilinenlerinizin tahmini, bugüne kadarki ilerlemeye göre ayarlanabilir. Bir ilk tahminde bulunabilir, ardından yaklaşık% 25 tamamladığınızda yeniden tahmin edebilirsiniz, sonra tekrar% 50'de ve sonra tekrar% 85'te. Her dönüm noktasında, tahmininiz görevlerin alacağı gerçek zamana yakınlaşmaya başlamalıdır.
Tahminlerim için kesin bir etiketleme sistemi kullanıyorum ... sınıf A, sınıf B ve sınıf C.
C sınıfı tahmini ilk aldıkları şeydir. Açıkça bilinmeyenler nedeniyle artı veya eksi% 50 olarak ifade edilir. Onlara B sınıfı vermeye devam etmemi istiyorlarsa, araştırmak için paraya ihtiyacım var.
B sınıfı artı veya eksi% 25'tir. Bazen bu yeterince iyi ve bana inşa etmem için para veriyorlar. Değilse, daha az para ve daha fazla araştırma.
A sınıfı artı veya eksi% 10'dur, son ve devam eder veya gitmez. Eğer bu bir giderse ve tahminlerden çok uzaklaşırsam, sık sık ve erken itiraf ederim.
"Daha önce deneyimim olmayan 3. taraf kontrollerini kullanan" ifadesini kaldırırsanız, daha büyük sorununuz için daha iyi bir açıklamaya sahip olabileceğinizi düşünüyorum.
"Çevik" bize bir şey öğrettiyse, yönetim sizden sürekli olarak projeleri bu şekilde tahmin etmenizi bekliyorsa ve bunun sağlanamayacağını söylerseniz "kötü görüneceksiniz" çünkü sahip olmadığınız yeterli bilgi, FAIL otoyolundasınız.
En büyük sorun, üzerinde kontrol sahibi olmadığınız ve henüz tanımlamadığınız konular olacak. Ne sıklıkla geriye dönüp kendinize şöyle dediniz: "Pekala, tahminimi hemen düğmeye bastım - üçüncü denemede, bunu anladıktan sonra ... ve versiyona ihtiyacım olduğunu ... ve dba'nın açık olacağını bir haftalık tatil ve Proje Yöneticisinin bana bir haftalığına ihtiyacı olacağını ve karımın hamile olduğunu ve ... ".
"Kritik risk faktörlerini belirleyebilirim ve bunları xx gün içinde test etmek için teslim edileceklerin bir kontrol listesi oluşturabilirim. Bu noktada size artımlı bir tahmin daha vereceğim."
Ve "Lütfen gelecekte size bu türden güvenilir bir tahmin vermeye çalışmam konusunda ısrar edin. Eğer denersem beni kovun."
(Abartılı, ancak çok az.)
Tahmin etmeye bile çalışmayın. Tahmininizin doğru olmasının hiçbir yolu yok. Sonuçta bu sadece bir tahmindir.
Bunun yerine özelliği küçük parçalara ayırmanızı (1-2 günden fazla olmamak kaydıyla) ve bu parçaları çalışan, eksiksiz, test edilebilir ve değerli kod olarak müşteriye / yöneticiye teslim etmeye çalışmanızı tavsiye ederim. Bu şekilde günlük ilerlemenizi kendisi görecek. Bu aynı zamanda, tüm hedeflere ulaşmamış olsa bile, tatmin olduktan sonra gelişimi durdurmaya karar verebileceği ve tamamlandığını düşünebileceği anlamına da gelir.
Bu yaklaşım hakkında daha ayrıntılı bilgi için Agile uygulamaları olan "Sürüm Planlama" ve "Yineleme Planlaması" na bir göz atın.
Daha büyük bir zaman tahmini talep ediyorsanız, ancak zaman içinde yaparsanız, tahmin etmekten ve bir uzatma istemekten çok daha iyi göründüğünü unutmayın.
Bir prototiple dalga geçmeye çalışırım, böylece ne kadar süreceği hakkında daha iyi bir fikriniz olur. Yönetiminize karşı dürüst olun, böylece öğrenme eğrisindeki beklenmedik gecikmeler için bütçe ayırabilirler.
DÜZENLEME: Daha "yinelemeli" bir son tarih alıp alamayacağınızı da görebilirsiniz. "Pragmatik Düşünme ve Öğrenme" de Andy Hunt, insanların projenin sonuna daha yakın proje uzmanları ve en başında en az bilgili oldukları konusunda iyi bir noktaya işaret ediyor. Herkesin proje hakkında en az bilgili olduğu en başta, tüm tasarımınızı ve zaman tahminini yapmak pek mantıklı değil. Son teslim tarihlerini "yinelerseniz" ve sorunu parçalar halinde çözerseniz, daha fazla başarı elde edersiniz.
Pek çok doğru tahmin öz-bilgidir. Çok fazla kod yazdıysanız, çok sayıda API öğrenmeniz gerekiyorsa, aşağıdaki gibi sorular için bir fikir edinmeye başlarsınız:
Bu süreçte, aşağıdaki gibi şeyler hakkında bir fikir edinmelisiniz:
Tüm bunlara dayanarak, bir şeyin ne kadar süreceği konusunda bir fikir geliştirebilecek ve ne yazık ki eksik bilgiler karşısında bile varsayımlarınızı ("API'nin mantıklı olduğunu varsayarsak ...") ifade edebileceksiniz.
Tahmin ne kadar bilmiyorum", örneğin, daha iyi bir tahmin yapmak için yeterli bilgi edinmek için gereken:. Bunu daha önce birlikte hiç işi ettik Muhtemelen beni alacak buradan tahmin insert dışarı çalışmak için neler Projenizi bitirmek için bunu kullanmak için size iyi bir tahmin yapmadan önce bilmem gereken bunu öğrenmeniz gerekiyor . "
Sadece dışarıdan bir sayı tahmin edersiniz ve hemen değerlendirmeye başlarsınız, gelecekteki bilgilerin tahminlerinizi etkileyebileceğini, ancak bunları güncel tutacağınızı bilmelerini sağlayın.
Değerlendirirken, web'de yayınlanan bir belge veya haftalık güncellemeler yoluyla onları bilgilendirin, ancak her zaman güncellenmiş bir "tahmini bitiş tarihi" ve uzantıların nedenlerini (varsa) ekleyin.
Çoğu yönetici şunu anlamalıdır - bitiş tarihlerini sorarak, gerçekten "bize programımızı nasıl planlayabileceğimiz konusunda bir fikir verin" ve "sonsuza kadar sürmeyin" diyorlar.
Bir veya iki defadan fazla uzatırsanız, tahmin etmekte zorlandığınız yeni bilgilerinize göre tüm programınızı yeniden değerlendirin.
Programlama yaparken her zaman beni alacağını düşündüğüm şeyi aldım ve bir tahmin sağlamak için bunu 3 ile çarptım. 1 hafta içinde bir iş yapabileceğimi düşünürsem, müşteriye bunun 3 süreceğini söylüyorum - gerçekten 3 hafta süreceğini düşünüyorsam, müşteriye 9 hafta söylerim.
Bunu yaparak kendimi "söz veriyorum, fazla teslim et" olarak ayarladım - eğer bunu başarılı bir şekilde yapabilirseniz hayatınız çok daha iyi olacak ve müşterileriniz son derece mutlu olacak.
Sizin durumunuzda, bir tahminde bulunmadan önce kesinlikle neye daldığınızı en azından BAZI anlamak isteyeceksiniz. Belki bir tahminde bulunmanın ne kadar süreceği konusunda bir tahminde bulunmanız bile gerekiyor. 3 ile çarpmak müşterileri mutlu eder.
Biraz deneyim sahibi olduğunuz şeylere ayırın. Parçalama eylemi size neyi bildiğiniz ve bilmediğiniz hakkında daha iyi bir fikir verecektir.
Parçalar tek tanımlı görevler olarak görülebilecek kadar küçük olduklarında, birkaçı tamamen tahmin edilemez olacaktır. Bunlar için, önce prototip yapın ya da parçanın boyutuna bağlı olarak kendinize makul bir süre bırakın. 2-4 haftalık bir işten daha büyük, tahmin edilemeyecek parçalara sahip olduğunuzu fark ederseniz, önce onları doğramaya geri dönün.
Sonunda bazı çok tuhaf teknolojik çözümlere (işe yaraması gerektiğini düşündüğünüz, ancak kesin olarak bilmediğiniz) ve bir kez işe yaradığında bu şeyleri desteklemek için yapılacak çok iş göreceksiniz. Birkaç parça eksik tasarım olacaktır, bunun için iyi bilinen bir kitaplık veya ilk sürüm için çok basit bir algoritma seçmek en iyisidir.
Görevleri kıramazsanız, bunu yapabilecek yeterli deneyime sahip birini işe almalısınız (deneyim eksikliğiniz sizi başka şekillerde de rahatsız edecektir). Birini işe alamıyorsanız, rastgele uzun bir süre için pazarlık yapmalı (6 aydan 2 yıla kadar) ve doğrudan dağınık bir prototipe gitmelisiniz (neyin doğru ve neyin doğru olduğunu bilmek için kendinize yeterince deneyim verene kadar. yanlış). Ancak, sonunda onu savurursanız, kendinizi kandırmamak ve bunu doğru "şekilde" yaptığınızı düşünmek önemlidir. Prototiplerin atılması gerekiyordu. Umarım prototip geri sayımı tamamlandığında, onu gerçekten inşa etmeye hazırsınızdır.
Paul.
RB'nin söylediğine ekledim, kendimi bu durumda bulduğumda aşina olduğum araçlarla ne kadar zaman alacağını tahmin ediyorum ve sonra bir öğrenme eğrisi oluşturmak için bu tahmini ikiye katladım.
Önemli olan, yönetime tahminin bir tahmin olduğunu iletmektir , eğer daha doğru bir tahmin için baskı yaparlarsa ya da - sevgili Tanrım - size bir zaman sınırı satmaya çalışırlarsa (kesinlikle Starship'i inşa etmeniz sadece 2 gün sürer Atılgan, sen iyisin) SİLAHLARINIZA YAPIN , tahmininizden veya bunun güvenilmez olduğu gerçeğinden ödün vermeyin.
Eğer yönetim sizi geçersiz kılarsa ve timebox görevi (örneğin, "Peki, 2 gün içinde yapılmalıdır"), yine onların tahminlerinin tam olarak sizinki kadar güvenilir olduğunu bildirin .
Tüm bunları yazılı olarak not edin.
İşimde tahminle epey uğraşıyorum ve bu gerçek bir zorluk. En büyük zorluklarımdan biri, farklı bir geliştiricinin bir görevi, geliştiricinin ne kadar yetenekli olacağına dair hiçbir bilgisi olmadan gerçekleştirmesinin ne kadar süreceğini tahmin etmektir.
"Vaat altında, gereğinden fazla teslim etme" yöntemiyle başlangıçta bir miktar başarı görebilirsiniz, ancak zamanla "fazla vaat, az teslim" düşünce okulunu izleyen diğer insanlar tarafından teklifin daha yüksek olacağını göreceksiniz. Doğruluk eksikliği sizi ısırmak için geri gelecektir. Doğruluk, teknoloji ile bilinmeyenlerin sayısını deneyimlemeye ve sınırlamaya çok bağlıdır.
Önereceğim bir şey, tahmininizin ne tür bir bütçeye karşı çalışacağına dair bir fikir edinmektir. Küçük bir bütçeniz varsa, bilmediğiniz teknolojiyle çıldırmayın ve bildiklerinize bağlı kalın. Bütçeniz biraz daha esnekse, biraz deneme yapabilirsiniz.
Ayrıca, sağlayabileceğiniz her şeyin bir Wild Ass Guess (WAG) olduğu bazı görevler olacağını da unutmayın. Bunlar için tahmininiz için minimum bir süre belirlemeli ve maksimumun ne olduğunu bilmediğinizi açıkça belirtmelisiniz. Çoğu zaman bu tür bir tahmin, belirli özelliklerin / gereksinimlerin yönetim tarafından çıkarılması için yeterli nedendir.
Bu, hem proje yöneticisinin hem de programcının sahip olabileceği (ve tabii ki ustalaşabilir!) Vazgeçilmez bir beceridir, bir makale buldum, Yazılım Geliştirme Görevlerini Tahmin Etmek (biraz) Daha Kolay , projenin görevlerinin daha iyi tahmin edilmesine yardımcı olmayı umuyorum.
Yukarıdaki yanıtların tümü, tahminin kendisi ile ilgili hemen hemen her şeyi kapsamıştır.
Vurgulamak istediğim bir şey, tahmininizi takip etmektir (Joel a la Joel, hatta çok basitse bir Not Defteri belgesi) ve her günün sonunda bunu şimdi sağlayabileceğiniz en doğru rakamlarla güncellemektir. . Bunu patronlarınıza geri iletmeniz gerekmese bile, bunu güncel tutmak size işlerin nasıl ilerlediği hakkında daha iyi bir fikir verir ve daha da önemlisi iş ilerledikçe tahmininizin neden değiştiğine dair iyi bir fikir edinirsiniz. .
Bunu yapmak, hem bu belirli teknoloji hem de daha önce kullanmadığınız diğerleri için gelecekte tahminlerde daha iyi olmanızı sağlayacaktır, çünkü beklentilerinizin ne zaman değiştiğini düzenli aralıklarla fark etmenizi ve bunun neden olduğunu çözmenizi gerektirir. .
Bir şeyin ne kadar süreceğini tahmin etmek işinizin bir parçasıdır. Bir son tarih değil, bir tahmin olduğu anlaşıldığı sürece endişelenecek hiçbir şeyiniz olmamalıdır. Bir tahminde bulunabilecek, kodu yazacak kişiden daha iyi kimse yoktur. İyi bir tahmin sağlayamazsanız, yönetimi kötü tahmininize bağlı riskten haberdar etmeniz gerekir, böylece bu bilinmeyen üçüncü taraf kontrollerine karşı programlama konusunda risk almaya değip değmeyeceğini yeniden değerlendirebilirler.
Bu çok yaygın bir durum: bilinmeyenle başa çıkma zorunluluğu. Bununla başa çıkmanın yararlı bir yolu, gerçek programlama görevlerinin yanı sıra, yapacak bir şeyler öğrenmeniz gerektiğini ve yönetimin bunun farkında olması gerektiğini fark etmektir.
Böyle bir durumda olduğunuzda proje birdenbire bir Ar-Ge projesine dönüşür ve normalden daha uzun bir süre sizi kötü göstermez çünkü öğreniyor ve programlar üretiyorsunuz. Ne kadar hızlı öğrendiğinizi veya bulabileceğiniz herhangi bir problemle başa çıkmanız için hangi kaynakları kullanmanız gerektiğini bilmiyorum (Stack Overflow, sahip olduğunuz seçeneklerden biridir).
Her zamanki gibi tahmin etmeniz ve ardından ya 1,5 (hızlı öğreniyorsanız ve sorularınızı çözmek için kaynaklara erişiminiz varsa) ya da ortalama bir öğreniciyseniz ve yalnızca kendinize güveniyorsanız 2,5 ile çarpmanız gerektiğini söyleyebilirim.
Umarım bu yardımcı olur!
Görevi yönetilebilir parçalara bölmek için elinizden gelenin en iyisini yapın. Biraz şansla, ilgili 3. taraf bileşenle ilgili ve daha az bağlantılı (ve dolayısıyla tahmin edilmesi daha kolay) diğerleri ile ilgili özel görevler vardır. Yönetime bölünmüş tahminler verin ve en belirsiz tahminlerin nerede yaşadığını gösterin.
Kimin etrafta oynamayı ve bazılarının prototipini yapmayı önerdiğine tamamen katılıyorum. Prototip oluşturma etkinliği için sabit bir zaman çerçevesi ayarlayın. ("Tahminimin bu kısmını daha iyi hale getirmek için önce iki güne ihtiyacım var.")
Bir aralık verebilir misin? 40-60 saat, böyle bir şey mi?
Görevler ne kadar küçükse o kadar zordur, eğer onları gruplandırabilirseniz, projenin sonunda hatalar dengelenebileceği için biraz daha "eğimli" olursunuz.
Deneyiminiz olan herhangi bir alana bakın ve eğer bir rehber olarak kullanın. "Veritabanını değiştiren bir özellik oluşturmak için en son gerekli bir X aldı". İyi şanslar.