Uygulamada doksan doksan kuralı

Kodun ilk yüzde 90'ı, geliştirme süresinin ilk yüzde 90'ını oluşturuyor. Kodun kalan yüzde 10'u, geliştirme süresinin yüzde 90'ını oluşturuyor.

- Tom Cargill, Bell Laboratuarları

Bu pratikte tam olarak ne anlama geliyor? Bu programcıların önemli miktarda çalışma yaptığını ve kendilerinin% 180'ini verdiklerini mi?

Şöyle düşünün: Yazılım üzerinde çalışmaya başladığınızda, nispeten kısa sürede çok miktarda kod yazabilirsiniz. Bu yeni kod büyük miktarda yeni işlevsellik katabilir. Sorun şu ki, işlevsellik "bitmiş" olmaktan uzak, böcekler, küçük değişiklikler (küçük işletmelerde küçük) olabilir. Dolayısıyla, yazılım neredeyse bitmiş gibi hissedebilir (% 90 yapıldı), çünkü kullanım durumlarının çoğunu destekliyor. Ancak yazılımın hala çalışmaya ihtiyacı var. Bu kuralın amacı, yazılımın neredeyse bittiğini hissetmesine rağmen, bu yazılımı düzgün çalışan bir duruma getirmek için gereken iş miktarının “neredeyse yapılan” duruma gelmek kadar büyük olmasıdır. Bunun nedeni, hata onarımının çoğu zaman zaman alması ancak çok fazla kod üretmemesidir.

Sorun, çoğu geliştiricinin, yazılımı "neredeyse bitmiş" duruma getirmeyi tahmin etmesidir, çünkü yazılımın harcayacağı toplam çabayı tahmin etmekle karşılaştırıldığında nispeten basittir.

Ne yazık ki bugün hala gerçekleşen ortak bir senaryoya referanstır:

1. Takımdan tüm kodu yazmak için gereken iş miktarını tahmin etmesi (yani tahmin etmesi) istenir,
2. Proje, "zamanında ve bütçede kalmak" için çok sayıda iç ve dış baskı ile devam ediyor,
3. Bu nedenle projenin önemli bir yüzdesi için "hedefte" olduğu bildirildi. Bu, genellikle iyi ilerleme kaydedilmesini sağlamak için önce kolay görevleri seçerek birleştirilir.
4. Sonra bir aşamada, gerçeğin kabul edilmesi gereken kritik bir noktaya ulaşılır: proje zamanında tamamlanmayacak ve çıkış tarihi geri itilecektir (çoğu kez).

"% 90" isteğe bağlı bir rakamdır, ancak konuyu iyi yapar: tahminler tahminlerdir ve muhtemelen yanlış olacaktır (genellikle çok yanlış) ve insan doğası neredeyse her zaman tahmin edilmemizi sağlar, bu yüzden işler aşılır.

Bunun gibi farklı bir versiyonunu ("90-90 kuralı" da denir) duydum:

İşlevselliğin % 90'ını uyguladıktan sonra, diğer% 90'ını hala uygulamak zorundayım .

Her iki versiyon da, yazılım ürünleri geliştirmek için gereken çabayı doğru tahmin etmenin zorluğunu ve insanların içine düşme eğilimindeki yaygın tuzakları ifade eder:

• tahminler gerektiğinde ve esasen tahmin edildiğinde istatistikleri ortaya koyma ("% 80 bitirdim")
• Yazılacak kodun algoritmik karmaşıklığına odaklanın, iş hacminin zararına (ortak görevler için gereken çabayı göz ardı edin)
• eksik adımlar ("görüş dışı, akıldan çıkmayan")
• mevcut kodu sürdürme ve değiştirme çabalarını hafife almak
• Kazan / "yapıştırıcı" kodu için gereken hafife alma çabası

Bu kural 80-20 kuralını tamamlar. Şimdi, 80-20 kuralının birçok farklı yorumu var, ama en çok hoşuma giden ikisi:

1. İlk% 80 ürün geliştirme çabasının% 20'sini almaktadır.
2. Hataların% 80'i kodun% 20'sinde.

Uygulamada, bunun anlamı şudur: Geliştirme, ilk gecikmelerin farkedileceği bir noktaya kadar başlayacak ve devam edecektir. Gecikmeler çeşitli nitelikte olabilir:

• Hatalı kalite kontrolü, böceklerle sonuçlanan
• Müşterinin yol boyunca karşıladığı ilave şartlar (ve bunun sebepleri de çok olabilir)
• Daha önceki gelişimin parçalarının düşmesine neden olan (gerileme hatalarıyla da sonuçlanabilen) baştaki belirsiz gereklilikler.
• Belirsiz kapsam, insan hatası veya öngörülemeyen koşullar nedeniyle başlangıçtaki küçük tahminler. Bu öngörülemeyen durumlar hasta yaprakları, istifalar, donanım arızaları veya aşırı durumlarda yanardağ patlamaları olabilir (bir keresinde İzlanda'daki bir yanardağ patlaması nedeniyle yerinde uçamadığımız için bir projeyi geciktirmek zorunda kaldık).

Sonuç olarak, hedefe yaklaşmak, hedefe ulaşmaktan çok daha kolay.

Vikipedi açıklaması oldukça aydınlatıcı buluyorum :

Bu, programlarını önemli ölçüde fazla çalışan yazılım geliştirme projelerinin saygınlığına,% 180'e varan bir oranla katma değer katmaktadır (bkz. Yazılım geliştirme çabası tahmini). Hem bir programlama projesinin kolay ve zor kısımlarına zamanın kaba tahsisini hem de birçok projenin gecikmesinin nedenini, sert parçaları öngörememek olarak ifade eder. Başka bir deyişle, bir projenin çalışması için beklenenden daha fazla zaman ve kodlama gerektirir.

Bu pratikte tam olarak ne anlama geliyor? Bu programcılar belirli miktarda iş yapıyorlar ve kendilerinden% 180 veriyorlar mı?

Hayır, programcılar her zaman birim başına aynı miktarda iş yaparlar. Alıntı, düşük tahmin ve maliyet aşımları hakkında. % 180, projenin maliyetini düşürdüğü zaman ve para miktarıdır.

Kabaca "Sizi düşündüğünüzden iki kez alacağınız" ve "Çok geç olana kadar (iyi bir zaman dolmak üzere) iyi iş yapacağınızı düşüneceksiniz" anlamına gelir.

Bunun pratikte anlamı, insanların kendilerine yalan söylemesidir.

Bir programcı "% 90 bitti" diyorsa, bu özellikleri oluşturma çabasının% 90'ı harcanmış demektir.

Bir proje yöneticisi "% 90 bitti, sadece bitirmesi için birine ihtiyacım var" diyorsa, bütçenin% 90'ı (ve muhtemelen% 50'si yapılır) anlamına gelir. Bu, parası olmayan, beklentileri yüksek ve olumsuz tutumu olan bir müşteri.

Fark, bir projeyi bitirmek için kodlama özelliklerinden daha fazla çaba harcamasıdır: qa, hata düzeltmeleri, kopya düzenlemeleri, dağıtım.

Bu şeylerin projede yönetilmesi gerekir ve proje yöneticisinin sorumluluğundadır. Bu, genellikle "% 90'ı tamamlandı" özelliğine sahip yeni Başbakanları şaşırtıyor, ancak "proje" nin sadece yarısı olduklarını fark ediyorlar.