Yazılım geliştirmede rutin çalışma miktarı ve tahmin üzerindeki etkisi

Yazılım geliştirmedeki rutin iş miktarının, ihmal edilemez olmasa bile nispeten küçük olması gerektiğine ve bunun yazılım tahmininin temel sorunu olduğuna ikna oldum.

Bu sonuca nasıl geldiğimi açıklayayım ve argümanın ciddi kusurları olup olmadığını söyleyeyim:

1. Yüksek doğrulukla tahmin edilebilecek tek şey, daha önce yapılan şeyler anlamına gelen rutin çalışmadır. Araştırma ve yaratıcılığı içeren diğer tüm işler gerçekten tahmin edilemez, en azından yüzde +/- 20'lik bir doğrulukla değil.

2. Yazılım geliştirme tamamen tekrar eden görevlerden kaçınmakla ilgilidir. Temel ilkelerinden biri KURU'dur (kendinizi tekrarlamayın). Bir programcı kendini tekrar eden şeyler yaptığında bulduğunda, bu tekrardan kaçınan bir soyutlama bulma zamanı gelmiştir. Bu soyutlamalar, yinelenen kodu bir işleve çıkarmak veya bir döngüye koymak gibi basit şeyler olabilir. Ayrıca, alana özgü bir dil oluşturmak gibi daha karmaşık olabilirler. Her halükarda, bunları uygulamak araştırma (daha önce herhangi biri yapmış mı?) Veya yaratıcılık içerecektir.

Bu iki noktadan yukarıdaki sonucu çıkarıyorum.

Aslında bir süredir neden bu ilişkinin diğer tartışmalarda, blog yazılarında veya yazılım tahminiyle ilgili makalelerinde bahsedilmediğini merak ediyorum. Çok teorik mi? Varsayımlarım yanlış mı? Yoksa çok önemsiz - ama neden tanıdığım çoğu geliştirici yüzde +/- 20 veya daha iyi bir doğrulukla tahmin yapabildiklerine inanıyor?

Verilen herhangi bir projede bu doğru olabilir. Bununla birlikte, yıllar boyunca farklı şirketler için birden fazla benzer projede çalışıyorsanız, temelde aynı sorunu birçok kez 'küçük değişiklikler ile' çözdüğünüz 'bulabilirsiniz.

Örneğin, veri erişim katmanlarını birçok kez yazdım, şimdi ayın popüler ORM'sini kullanmak yerine 'uzun el' yapmayı tercih ediyorum. Bilinen çözümlerle 'rutin problemlerle' başa çıkmak benim için 3. parti bileşenlerde yeni gariplikler bulup çözmekten daha hızlı ve daha kolay.

Açıkçası, başka birinin sistemindeki bilinmeyen tuhaflıkları eklemeden tekrarlayan kodu basitleştirmek için kendi ORM'mi yazabilirim, ancak bu kod o anda çalıştığım şirkete ait olacaktı ve diğer geliştiriciler de bunu herhangi bir 3. taraf ORM.

Benzer şekilde, tecrübelerime göre, çoğu programlama iş süreçlerinin otomasyonudur ve her işletme süreçlerinin kendilerine özgü olduğunu düşünmeyi sevmesine rağmen; Gerçekte öyle değiller.

Tahminin kolay olduğunu söylememek! Daha kolay, ancak bu günlerde tahmin sorunun kodlama için harcanan zamandan ziyade gereksinimlerin yetersizliğinden kaynaklandığını düşünüyorum.

Gereksinimler üç kategoriye ayrılır:

1. Belirsiz, ayrıntılar geliştiriciye bırakıldı.

"Bana bir web sitesi yap, havalı olmalı ve widget'larımı satmalı"

Bunlar, tahmin edilmesi en kolay olan eğilimdir, çünkü beklenmedik bir sorun ortaya çıktığında, gereksinimleri işlevsel olarak eşdeğer bir şeye değiştirebilir ve sorunu önleyebilirsiniz.

2. Çok özel

"Başlık arka plan rengini yap # ff1100"

Süper hızlı yapmak ve yine tahmin etmek kolaydır. Fakat! gereklilik değişmek zorundadır. "Hmm hayır ikinci düşünceler, bunu diğer kırmızı deneyin" veya "Bekleyin! Ben sadece o sayfada demek istedim!" yani "başlık renginden ne kadar memnun kalsam ne kadar süre" gerçek zaman dilimi kodlama tahminleri ile ilgisi yoktur

3. Belirsiz, varsayılan detaylar

"Bana bir web sitesi yap (tıpkı facebook gibi)"

Burada çok sayıda varsayılmamış varsayım, "tabii ki farklı bir logo isteyeceksiniz", "sonsuz kaydırma olmalı", "1 milyar kullanıcı için ölçeklenebilir olmalı!" tahmini etkili bir şekilde kontrol eder. Ya dev her şeyi düşünür ve tahmini beklentileri "1 meeelion adam saat" in ötesine iter, ya da sadece temel özelliklerin gerekli olduğunu düşünür / varsayar ve çok düşük bir tahmin verir. "Ah, bir iki hafta, facebook'u bir iframe'e koymak istediğinizi varsayalım değil mi?"

Deneyim ile kodlama çok hızlıdır, ancak gereksinimleri tasarlamak (genellikle) zor bittir ve bu giderek kodlayıcı olmayanlara geri gönderilir. Çevik metodolojilerle bu sorumluluğu geliştiriciler yerine 'işletmeye' taşıyarak kodlama hızını arttırmak.

neden tanıdığım çoğu geliştirici yüzde +/- 20 veya daha yüksek bir doğrulukla tahmin yapabildiklerine inanıyor?

Çünkü sorunla ilgili sabrımızı gerçek problemden çok daha fazla tahmin ediyoruz.

Zıplayan bir topu canlandıracaksam, bir gün, bir hafta, bir ay veya bir yıl geçirebilirim ve yine de zıplayan bir topun animasyonunu alabilirim. Umarım daha fazla zaman harcayacağım daha iyi görünecektir, ancak bir noktada saçma oluyorum.

Topun zıplaması için ne kadar çaba harcadığım, üzerinde harcamak için makul bir zaman fonksiyonudur. Beceri seviyem kesmiyorsa, orada oturan bir topla sonuçlanabilirim. Ancak son başvuru tarihi geldiğinde, son başvuru tarihinin kaymasına izin vermeli miyim yoksa en azından ekrana bir top mı getirmeliyim? Şelale, topun zıplaması için ısrar etti ve program kayboldu. Agile, topu oraya çıkar dedi. En azından insanların zıplamayı ne kadar önemsediğini öğreneceğiz. Böylece kalite düştü.

Toplarımın sıçradığından emin olmaya çalışıyorum, ancak son teslim tarihi geldiğinde statik bir top üretmek hiç yoktan daha iyidir. Bu yüzden, alternatifler hakkında konuşmadan önce, bir soruna harcamak için makul bir süre gibi görünen zamanı temel alarak zamanı tahmin ediyorum. Bazen top zıplamayacaktır. Bazen sorun değil. Bir ay boyunca kaybolmak sorun değil.