"Ne zaman yapılacak?"

Hepimiz var, düzeltilmesi zor olan problemler ve belirsiz kod ve tuhaf beklenmedik işlevsellik ile bir düzeltme çalışması. Yavaşça, mantıksal olarak kalıpları, hataları, hataları bulmaya çalışarak yolunuza devam edin. Bu işlem zaman alır ve sorunlar genellikle müşteri tarafından kolayca anlaşılamaz.

"Müşteri ne zaman yapılacak?" Sorusu sorulduğunda, özellikle istemci yazılım geliştirmenin doğasında var olan karmaşıklıkları anlayamayabildiğinde nasıl cevap verilir?

Soruyu dürüstçe cevaplıyorsun.

Onlara zor bir sorun olduğunu söylüyorsunuz, çözüm açık değil ve çözmenin ne kadar süreceğini bilmiyorsunuz. Her [zaman diliminde] ilerlemenizde bunları güncelleme sözü verin, böylece üzerinde çalıştığınızı bilirler ve elbette onlara güncellemeleri gönderirler.

Geliştiriciler karmaşık bir soruna, daha küçük olanlara ayrıştırıp ayrı olarak çözerek yaklaşırlar.

İdeal bir dünyada , bir sorunu çözmek karmaşık bir A problemi olacaktır ve belirli bir zamanda, A ₁ ila A _n arasındaki küçük problemlerin kısa bir listesine ayırabileceksiniz. ilk karmaşık problemi çözmek için gereken sürenin:

ile D ayrışma kendisi bir işlem olma.

Gerçek dünyada tek sorun, t ( D ) 'nin küçük problemleri çözmek için harcadığınız zamandan daha büyük olması. Başka bir deyişle, sorunun bu düzeyde ayrışmasına ulaşmak için, pratik olarak sorunun kendisini çözmeniz gerekir.

Hala yapabilirsin:

• Verilen görevi (sorunu çözerek) daha küçük parçalara ayırın, her bir parça hala karmaşık bir sorundur,

• Her bir yığın için beklenen süreyi ve ilgili riski değerlendirin.

  Örneğin, görev 1 için yakl. 5 saat, ancak bunu engelleme riski yüksektir, bu nedenle müşteriye beklentiniz olarak 12 saat verin.

• Bağımlılıkları ve zamanı nasıl etkilediğini değerlendirin.

  Örneğin, görev 19 2 saat gerektirir ve risk o kadar düşüktür ki, kesin olarak 2 saat olduğunu söyleyebilirsiniz. Not 1 değil. 3. Görev 19, görev 24'e dayanır: görev 24, görevi 19 farklı bir yaklaşım kullanarak görevin 19 kodunu tamamen yeniden yazmanızı gerektirecek şekilde etkileyebilir.

• Tüm bu ayrıntıları müşterinize verin. Toplamı vermeyin.

Son nokta önemlidir. Toplamı verirseniz, 192 saat diyelim, müşteri bunun çok hassas bir metrik olduğuna ve harcayacağınız sürenin, örneğin 189 ila 195 saat arasında olduğuna inanıyor.

Bunun yerine ayrıntıları verirseniz,

• İlgilenen müşteri bunun 192 saat olmadığını anlayacak. Değerlendirme sırasında belirlenen risk göz önüne alındığında her şey ters giderse 192 saattir. Ayrıca her şey daha da kötüye giderse 238 saattir. Her şey yolundaysa 85 saat.

• Umurunda olmayan müşteriye gelince, her durumda cevabınızı okumaz. Seni daha sonra suçlayabilmek için tek istediği bir numara. Asla okumayacağı çok ayrıntılı bir cevap vererek biliyorsunuz ki, bir daha süreceği zamanı sizden isteyemez: zaten cevapladınız. Ayrıca daha sonra suçlayamaz, çünkü toplamı hesaplamak için cevabı okumadı.

Tahmininiz ne olursa olsun Hofstadter yasasını dahil etmeyi unutmayın: Hofstadter yasasını göz önünde bulundurduğunuzda bile her zaman beklediğinizden daha uzun sürer.

Genellikle CPM / PERT'den değiştirilmiş bir formül kullanıyorum. Bunun gibi bir şey:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Tüm süslü matematik biçimlendirmesini nasıl yapacağımdan emin değilim; birisi bunu düzenlemek istiyorsa, çekinmeyin.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Projenin nasıl gittiğine bağlı olarak önemli ölçüde değişebileceğini vurguluyorum. Projenizi birkaç günde bir yeniden değerlendirirseniz, haftalık güncelleme bile sağlayabilirsiniz. Huzursuz müşterileri tatmin etmek için uzun bir yol kat ediyor. :)

Belirsiz zaman çizelgelerini teknik olmayan kullanıcılara açıklamak zordur. Bu, hem projenin yaratıcı aşamalarında hem de sinir bozucu bir hatayı takip ederken geçerlidir. Her iki durumda da geleneksel "işi daha küçük parçalara ayırın" da işe yaramaz.

Orijinal görev ikinci duruma odaklanır, bu yüzden üzerinde duralım. Zaman çizelgesi veremiyorsanız, kullanıcıya ne deneyeceğinizi ve ne zaman geri döneceğinizi söyleyin. Kendi kendine uygulanan zaman çizelgesinin yarısına geldiğinizde kısa ve dürüst bir e-posta güncellemesi verin. Son başvuru tarihinden en az bir saat önce resmi yanıtınızı verin. Artık güvenilirliğiniz var. Sorun en azından çözülmezse, biraz ışık tutuyorsunuz. Zaman kaybı gibi görünebilir, ama değil.

Bilinmeyen birlikte gösterimleri ve öngörülemeyen sürprizleri hesaba katamayacağınız için, güvenle tahmin etmek zor olabilir. fikirler:

• Bir dizi deneyin - "Ben emin ki, en azından N gün (örn 3) alacak, ama belki 4N gibi birçok olarak alın."
• Tahminleri tahmin etmek ve savunmak için daha üst düzey mühendislerden destek alın.
• İş değeri (güven ve güven kazanma) kazandıran minimum kod üretmek için daha kısa yinelemelerde (Agile / Scrum stili) çalışın ve tekrarlayın.
• Müzakere becerilerini klasik Başlarken Evet gibi bir kitaptan öğrenin (http://www.amazon.com/gp/aw/d/0143118757).

Yeni gelişme için, özellikle Çevik gelişme için:

"Eklenecek başka bir şey olmadığında değil, götürülecek hiçbir şey kalmadığında mükemmellik elde edilir." - Antoine de Saint-Exuper

Eğer çok samimi ve çok karmaşık bir sistemde hata (lar) üretmek için neredeyse imkansız bazı hataları düzeltmek için çaba ve zaman tahmin ediyorsanız çok az sistem samimi alan bilgisi olan hiçbir geliştirici ile o zaman tek doğru cevap "Ne zaman düzeltildi" dir.

Tipik olarak, sadece gerçeği söylerdim. Onlara şu anda bilmediklerini söyleyebilirim ve bir hafta içinde daha iyi kavrayışım olabilir. Daha sonra onlara bir bağırsak hissi tabanlı tahmin olduğunu belirtmek için kağıda sığdırabileceğiniz kadar çok dalgalı bir top parkı verirdim. Sizi zorlamaya başlarlarsa, her cümleye "Mümkün ..." ile başlayın. Genellikle bir şey yaptığım herkes "Bir hafta içinde tekrar kontrol edin, ama şimdi söyleyebileceğim tek şey yaklaşık 2 ay" ya da böyle bir şey.

Kişisel Yazılım Süreci (PSP) tahminlerin iyileştirilmesine odaklanmaktadır. Bu, görevlerin disiplinli günlüğü ile elde edilir. Bu, özünde, tipik görevler hakkında gerçek verilere sahip olacağınız için, tahminin "deneyim" bölümünü bir şekilde "hızlandırır". Tabii ki, bu meslek hala birçok soruna benzersiz çözümler gerektiriyor, ancak deneyimlerime göre, PSP'yi kullandıktan sonra tahminler daha iyi.