Yazılım programlarını tanımlamak neden bu kadar zor?

Tecrübelerime göre mühendislerin doğru bir şekilde tahmin etmelerini ve tamamlanması gereken görevleri belirlemelerini sağlamak, diş çekmek gibi bir şey. Sadece 2-3 hafta veya 3-6 aylık bir yağma tahmini vermek yerine ... yazılım programlarını tanımlamanın en kolay yolu nedir? Örneğin, müşteri A, 02.01.2011 tarihine kadar bir özellik istiyor. Yol boyunca diğer hata düzeltmelerine ihtiyaç duyulabileceğini ve ek mühendislik süresi gerektirdiğini bilerek bu özelliği uygulamak için zamanı nasıl planlıyorsunuz?

Tanıdık araçlar ve tanıdık bir ekip kullanarak, yaptığınız diğer projelerle neredeyse aynı olan bir projeyi kesiyorsanız ve size kesin ve yazılı gereklilikler verildiyse, iyi bir tahminde bulunmanız mümkün olmalıdır.

Bunlar, ressamların, halı montajcılarının, peyzaj planlarının vs. düzenli olarak yaşadığı durumlardır. Ancak birçok (veya çoğu) yazılım projesi için uygun değildir.

Sık sık, ihtiyaç duyulan yerlerde yeni araçlar, teknolojiler, vb. Kullanılan projeleri tahmin etmemiz istenir. Bu, geçmiş deneyimlerimiz üzerinde enterpolasyondan ziyade bilinmeyene göre ekstrapolasyondur. Bu yüzden tahmin etmenin daha zor olacağı doğal.

Kişisel tecrübeme göre, Pemdas'ın söylediklerinin tam tersi : pratikte, bir görevin ne kadar zaman alacağını tahmin etmenin tamamen imkansız olduğunu anladım. Yazılım geliştirmedeki kariyerimin başında, genellikle "45 gün", "beş hafta" gibi tahminler verdim, sonra zaman içinde bitirmek için çok uğraştım. Birkaç yıl sonra, "yaklaşık bir ay", "beş ila yedi hafta" gibi daha az kesin tahminler vermeye başladım. Aslında, herhangi bir tahminde bulunmamaya çalışıyorum ya da müşteriden kendi tahminde bulunmasını istemiyorum. veya son tarih veya mümkün olduğunca kaba bir tahmin veririm.

Bir tahminde bulunmak neden bu kadar zor? Çünkü bütün kaynak kodun gerçekte yazmadan önce nasıl yazılacağını bilmek neredeyse imkansızdır, çünkü çalışmanız diğer halklar, motivasyonunuz, vb. Gibi rastgele şeylere dayanır. İşte olası nedenlerin daha ayrıntılı bir listesi:

1. Bunu bilmek kolay değil , özellikle tam bir ürün yapmak için nelerin gerekli olduğunu ve nasıl bunu yapmak için . Çoğu zaman bir uygulamanın bazı bölümlerine başladım, çalışma günlerinden sonra ilk yaklaşımımın yanlış olduğunu ve iş yapmanın daha iyi ve daha akıllıca bir yolu olduğunu anladım.

2. Bazı problemler ortaya çıkabilir . Örneğin, çalışmanıza başlamak için makinenize şık bir SQL sunucusu kurmanız ve kurulumun başarısız olması ve desteğin mevcut olmaması durumunda, bu sorunu çözmek için haftalar harcayabilirsiniz.

3. Gereksinimler genellikle yeterince açık değildir , ancak başlangıçta bunları okuduktan sonra, öyle olduklarını düşünüyorsunuz. Bazen, 'A' anlamına geldiğini anlayabilirsiniz ve onları uygulamaya başladıktan sonra, belki de 'B' anlamına geldiğini farkedeceksiniz.

4. Müşteriler, ilgili kısmı yeni bitirdiğinizde gereksinimlerini tam olarak değiştirmeyi severler ve neden küçük bir değişiklik yapmaları için iki hafta ve 2000 ABD doları istediğinizi gerçekten anlamıyorlar , çünkü bu küçük değişimin gerektirdiğini görmüyorlar . başkalarını değiştirmeyi gerektiren diğer şeyleri değiştir, vb.

5. Motivasyonunu tahmin edemezsin . Saatlerce çalışabileceğiniz ve başarılı olabileceğiniz günler var. On satırlık bir kod yazdıktan sonra Programmers StackExchange'e geçtiğiniz ve soruları yanıtlamak için saatler harcadığınız haftalar vardır.

6. Tahminin diğer insanlara bağlı olduğunda işler gerçekten kötüleşir . Örneğin, 2 aylık bir projede, bir tasarımcının işimi kendim bitirmesini beklemek zorunda kaldım. Bu tasarımcı, kullanılamaz bir bok parçası teslim etmeden 3 ay önce aldı. Tabii ki proje gecikti.

7. Tahmininiz ayrıca müşterinize de bağlı . Postalarını yanıtlamadan önce haftalarını harcayan müşterilerim vardı. Cevaplarını beklemeniz gerektiği zaman çizelgenizi gerçekten etkileyebilir (örneğin, bir gereksinimi kesin olarak belirtmelerini rica ediyorsanız).

Ne yapabilirsin?

1. Daha büyük bir program ver . İşi iki hafta içinde yapabileceğinizi düşünüyorsanız, bir ay içinde teslim edeceğinizi söyleyin.

2. Açık ol . Bir tasarımcıya, başka bir geliştiriciye vb. Güveniyorsanız, söyleyin. "Ürünü üç ay içinde teslim edeceğim" demek yerine, "Tasarımcının bana PSD dosyalarını vermesinden sonra ürünü iki ay içinde teslim edeceğim" deyin.

3. Gereksinimler her gün değişirse, projenin zamanında teslim edilmeyeceğini açıklayın.

4. Programınızı dilimleyin . Büyük bir projenin parçalarını zamanında teslim etmek daha kolaydır.

5. İyi tanımadığınız bir ürünü kullanırken, özellikle de başkasının kaynak kodu üzerinde çalışacakken asla bir tahminde bulunmayın: kaynak kodun ne kadar berbat olacağını ve ne kadar zaman harcayacağınızı asla tahmin edemezsiniz. Anlamak ve kopyalamak için Günlük WTF'e yapıştırma.

Çok benzer bir soru "Bu bulmacayı çözmek ne kadar sürer?"

Bunun gibi sayısız şeyi görmek için bir göz atıncaya kadar cevap veremezsiniz:

• Tanıdık bir dilde mi? (İspanyolca İngilizceye karşı Çince)
• Daha önce çözdüğümüz türlerden biri mi? (Örneğin bir dergide çalışan bir seri)
• Müşteri adaylarından herhangi biri, anlayabilmemiz için ek bilgi gerektiriyor mu?
• Bulmacanın herhangi bir yerinde, bilginize ek iş gerektirecek şeyler var mı?

Bir projede genellikle birkaç yeni şey olduğundan (aksi takdirde bir proje olmaz), onlara çok dikkatlice bakana kadar çözmeleri ne kadar zaman alacağını söyleyemezsiniz. Belki daha fazla veya daha azını veya daha fazlasını çözebilir ve daha sonra onları düşünmediğiniz bir veya iki sürpriz olmadığından hala emin değilsiniz.

Ayrıca, mümkün olduğu kadar ucuz bir şekilde yapılabilmesi için güçlü bir baskı var, bu yüzden mümkün olduğu kadar çabuk ve çok düşük bir tahminin suçlanması, proje yöneticisine baskı uygulayarak değil, tahminde bulunan geliştiriciye devam ediyor. Geliştiricinin bunu yakalaması için pek çok yineleme gerektirmez ve mutlak sayılar vermekten çok bıkmış olmayı öğrenir.

Mühendislerinizin size doğru tahminler verememesinin en açık nedeni bunun imkansız olmasıdır .

Tabii ki evinizden işe yaramanız için ne kadar zaman + -2 dakika alacağınızı tahmin edebilirsiniz. Araba kullanmayı biliyorsunuz, trafiği ve diğer bazı dış faktörleri değerlendirebilirsiniz.

Londra’dan Barselona’ya gitmenin ne kadar zaman alacağını bana söyle. Elbette herhangi bir gelişmiş GPS planlama aracı olmadan. Oldukça eski olan yöntemi kullanarak hala yazılım tahmininde bulunuyoruz. Ampirik tahmin ve tahminler .

Yazılımda daha kötüsü:

1. Tahminler genellikle bir taahhüt haline gelir , bu nedenle kararımız değiştirilir.
2. Aynı görev için Bob ve Karl'ın tahmini arasında büyük farklılıklar olabilir .
3. Belirsizlikler çok yaygındır, ne kadar aptalca bir hataya ya da sabit disk çarpmalarına sıkışıp kaldığımızı, görünürde iyi bir tahminde bulunmadık.
4. Genellikle toplantılar, telefon görüşmeleri, meslektaşlarımıza yardım etme vb. Dahil olmak üzere programlama dışındaki tüm işleri unuturuz.
5. İnsan beyni sınırlı . Uzun süren görevleri tahmin etmek için tasarlanmamıştır.

Bu nedenle, müşterinize 02/01/2011 için neleri göndereceğinizi iyi bir doğrulukla söyleyemezsiniz ve 03/01 / 2011'i unutun.

Tüm bu sorunları gidermek için, Planlama Poker (feragatname: web sitemden biri) ve Hız hesaplama ile İteratif Gelişim gibi gelişmiş tahmin teknikleri öneririm .

• İlk iki konu Planning Poker kullanılarak ele alınmıştır. Tahminler kolektiftir ve ekip bireylerden ziyade onlara sahiptir.
• Son üçüncü konular, Hız ve İteratif Geliştirme kullanılarak ele alınmıştır. Hızınızı bilerek (tarihe dayalı tahminlerinize uygulanacak faktör), sürümleri daha güvenle planlayabilirsiniz. Yinelemeli gelişim, iyi yapıldığında, en önemli özellikleri en üst seviyeye getirir ve kullanıcılarınıza erken değer katmanıza yardımcı olur.

Yazılım geliştirme - tanım gereği bir keşif ve buluş eylemidir. Her zaman bilinmeyen bir şey içermelidir.

Yazılım geliştirme ile ilgili her şeyin bilindiği tek zaman, yazılımın ne zaman gerçekleştiğidir.

Bilinmeyen bir teknoloji veya işletme özelliği bulunmayan tek zaman, indirmeye hazır, eksiksiz ve paket bir çözümdür.

Yeni yazılım yazmamızın nedeni, yeni bir özelliğe veya yeni bir teknolojiye ya da her ikisine de sahip olmamızdır. Yeni, yeni - bilinmeyen - öngörülemez anlamına gelir.

Yazılım geliştirme yenilik içermesi gerektiği için geliştirme çabası tahmin edilemez.

Açıkçası, sadece pratik gerektirdiğini düşünüyorum. Sonunda yeterince kod yazarsanız, "oldukça" doğru olmalısınız. İlk patronum, bu yeteneğin, uyguladığım her özellik / projede gayri resmi olarak pratik yapmamı talep etmesinin yeterince önemli olduğuna inanıyordu. Her projeden sonra tahminleri inceledik ve nerede yanlış yaptığımı anlamaya çalıştık. Sonunda, onu asmak.

Asla kolay değil. Sadece daha iyi olmaya çalışın.

Verilebilir kodunuzu daha küçük parçalara ayırmanın bir avantajı, müşterilerin ne bekleyeceği ve ne zaman bekleyeceği konusunda bilgi sahibi olmalarıdır. Şimdi referans olarak kullanmaları için bir çeşit temeliniz var.

Belirli bir zamanda ihtiyaç duydukları bir özellik için kesin bir tanımları varsa, bu talebe ek kaynakların tahsis edilmesi gerektiğini bilmeleri gerekir. Meydana gelen hataların ciddiyeti ve düzeltilmeden ne kadar sürebilecekleri konusunda risk alıyorlar. Büyük bir şey ortaya çıktığında, müşteriye geri dönüp bir karara varmaya zorlarsınız. Bu hatayı düzeltir miyim veya yeni özellik için son tarihi belirleyebilir miyim? Bilgilendirilmiş bir karar vermeleri için onlara yeterince bilgi verin.

Umarım birlikte çalışacak kadar geçmişiniz vardır ve güvenilecek kadar kendiniz kurmuşsunuzdur. Gelişim sürecini tam olarak anlamalarını bekleyemezsiniz, ancak dürüst bir çaba gösterdiğinizi ve bilgi eksikliğinden yararlanamadığınızı hissettirmelerini sağlayabilirsiniz.

Çünkü programı çok erken yapıyoruz. Bkz Construx makalesini sonra o zaman daha iyi bir, bir ön kaba birini yaparak üzerinde. Ayrıca, önceki tahminlerde nasıl yaptığınızı izlemezseniz, daha iyi olmak zordur. FogBugz bunu yapar [serbest olan müşterisi, başka bir çıkar çatışması yok].

Bu kitaptan çok şey öğrendim:

Yazılım Tahmini: Siyah Sanatın Demonte Edilmesi

Kısacası, daha iyi tahmin sonuçları elde etmek için şunu yapıyoruz:

1. önemsiz görevler dışındakilerin hepsi birden fazla kişi tarafından tahmin edilir (bizim durumumuzda iki tane)
2. görevi daha küçük göreve bölüyoruz. Ne kadar çok görev görürseniz o kadar çok tahmininizin iyi olacağını tahmin edersiniz.
3. en kötü, en iyi ve en muhtemel senaryoyu tahmin ediyoruz. Bazen her birimiz bu ağaç senaryolarını tamamen farklı tahmin ediyoruz. Bu, konuşmamız gerektiği ve genellikle birimizin görevi anlamadığı anlaşılıyor. Bu kişi tek başına görevi tahmin etmiş olsaydı, yanlış olduğu tahmin edilebilirdi.
4. Yukarıdaki noktadan 3 sayı koyduk ve denklem aldık

İşimiz bittikten ve tahminimiz yanlış olduktan sonra nedenlerini bulmaya çalışıyoruz. Ve bu bilgiyi bir sonraki tahmin sürecine dahil ediyoruz. Şimdiye kadar bu, daha büyük görevlerin tahmininde kullandığım en iyi süreç. Görev derken, yaklaşık 50-500 saat süren işler demek istiyorum.

Not: Bu gerçekten yalnızca sabit / sabit orana karşı saat başı faturalandırdığınız projeler için geçerlidir.

Genelde programımı planlamaya çalışırım, böylece temelde bir grup SCRUM Sprints (SCRUM kullanıyor olsun veya olmasın) oluşur. Takvimi yaparken her bir sprintin uzunluğunu ve proje için özelliklerin ne olacağını belirlerim. Tipik olarak, ilk önce yapılması gereken bazı özellikler vardır, bu nedenle, bunlar için en iyi tahminde bulunmaya çalışıyorum (iyimser değil), projenin sonuna doğru olacak özellikler genelleştirilmiş tahminlere sahip olacak. Özellikleri sprint'lere eşleştirdikten sonra, doğru kaydırılan özellikleri ve orijinal gereksinim toplanmasında göz ardı edilen özellikleri hesaba katmak için projenin kuyruğuna 1 ila 2 sprint eklemeyi deniyorum.

Bunun anahtarı, müşteriye açık bir şekilde tüm bunları şeffaf hale getirmemdir, böylece son iki sprintin neden boş veya seyrek doldurulduğunu anlarlar. En azından bu noktada müşteriyle birlikte çalıştığım müşteriler bunu sevdiler çünkü çoğu zaman SW tahminlerinin somuttan daha az olma eğiliminin olduğunun farkında olduklarından, program / finansta bazı yastıklar olduğunu biliyorlardı. Ayrıca son sprinte ihtiyacımız yoksa ya da o zaman faturalandırmadığımız saatlerin olduğunun farkındalar. Programın nasıl yapıldığındaki şeffaflık ve projenin yürütülmesi sırasında nasıl bir ilerleme kaydedildiğine dair düzenli geri bildirimlerle, bunu yaptığım her müşteri son derece memnun kalmıştır.

Tüm bunlara ek olarak, bu iki şeyi en büyük sorunlardan bazıları olarak görüyorum. Öncelikle, haftanın 5 günü, günde 8 saat boyunca müsait olan her devir sahibine göre son tarihi tahmin ediyorsun. Bu yanlıştır ve neredeyse% 100 önemsiz olmayan herhangi bir projede bitiş tarihinin kaçırıldığını garanti eder. İnsanlar zaman ayırır, şirket (veya proje temelli olmayan) toplantılara katılır, sağlık sigortası talepleri konusunda İK ile mücadele eder, mola verir, vb.

Sıradaki geliştiriciler, proje, dağıtım, KG desteği, UAT desteği, birim testleri, araştırma, dokümantasyon vb. İle ilgili toplantı ve e-postalar gibi tüm gelişim dışı görevleri tahmin etmeyi unutuyorlar. tahminler daha da iyi oldu.

Birkaç saatten uzun süren işler için zaman tahmini söz konusu olduğunda, bu kuralları kullanmak için elimden geleni yapıyorum:

1. Etmeyin hiç sen buna bağlı olur, diğer insanların işini bitirmek ne zaman tespit etmeye çalışmaktadır. Sadece kendin için konuş.
2. Önce görevi analiz et, sonra tahmin et. Analiz ederek, en azından her biriniz için tahmini bir alt görev listesi yazmayı (ve içinizdeki her şeyi kafanızda tutmaya çalışmıyorum!) Kastediyorum.
3. Bir görev yeterince karmaşıksa, böyle bir analiz için zamanı tahmin edin. Tahmin ayrı bir süreç olsun. Ayrıca patronunuzun bunu bildiğinden emin olabilirsiniz.
4. Baskı altında tahmin etmeyin. Makul bir tahminde bulunmanın zaman aldığını açıkça belirtin ve onlara “görevi analiz etmeyi bitirdiğimde yarın 11: 00'a kadar bir tarih vereceğim” gibi bir şey söyleyin. Bazı müşterilerin / yöneticilerin zorla basabileceğini biliyorum ama geçemeyecekler. Meşgul yüzünü giy ve zamanını talep et!
5. İhtiyacınız olduğunu düşündüğünüzden biraz daha fazla zaman isteyin, çünkü tahmininize muhtemelen bir kahve molası zamanı (ve diğer zorluklar) eklemeyi unutmuşsunuzdur.
6. Büyük işler için daha fazlasını isteyin - muhtemelen birden fazla kahve molası verilir.
7. Gerçekten tahmin edemiyorsanız (görev çok zor / yabancı) veya gerçekten emin değilseniz - analizinize yardım edebilecek birinden sorun.

Muhtemelen bundan daha fazla kural var, ama aslında duvarımda bu kuralları içeren bir posterim yok. Onları şimdi formüle ettim, ancak deneyimlerimden geliyorlar (bu yüzden sizin için çalışmayabilir).

Zamanlama yazılım geliştirme için tek güvenilir yolu Aklıma gelen (ama aslında hiç denemedim) 'dir Kanıt Temelli Planlama temelde 'sen misin görevler hakkında tarihsel kayıtlar esas alınarak bir gemi tarih olasılığını saymak için kullanılan Monte Carlo yöntemidir daha önce başardım. İyi hissettiriyor çünkü tahmini ve gerçek zaman dışındaki ölçümleri kullanmaya çalışmıyor. Ancak, büyük görevleri önceden küçük işlere bölmek için çok fazla tecrübe gerekir ve yeterince çalışmasını sağlamak için büyük bir geçmiş verilere sahip olmanız gerekir.

Orada "bilinen bilinmeyenler" ve "bilinmeyen bilinmeyenler." :-)

1. Tahminler genellikle son tarihler olur.

   • Kimse son tarihi kaçırmak ve manşet olmak istemez!

2. Gereksinimler (genellikle rasyonel olarak) değişir ve programcı bunu veto edemez.

3. Programcı gibi faktörler üzerinde kontrol sahibi olabilir / olmayabilir

   • Bağlı olduğu kodun kullanılabilirliği
   • Bağlı olduğu kodun kalitesi
   • Genel mimari ve sistemin tasarımı
   • Sistemin diğer bölümlerine erişmek için API'ler