Karşı bir soru sormak istiyorum:
Kapsamını sabit + sabit tarih + hiç iş, yapılacak fiyat sözleşme sabit Can dönemi ?
"İyi / hızlı / ucuz - iki tane seç" demesi aptalca bir mühendislik şakası değildir. Tuzu olan her proje yöneticisi Proje Yönetimi Üçgeni'ni bilir :
Bize maliyet, kapsam ve zamanlamanın tamamen sabit olduğunu söylüyorsunuz. Bu manevra kabiliyeti veya hata için yer bırakmaz. Yok . "Kalite" yi bir nitelik olarak görüntülemeyi seçebilirsiniz, ancak "gerçek" bir özellik değildir, daha çok diğer özelliklerden türetilen bir meta-nitelik gibidir (maliyet / kapsam / program).
Sorun şu ki , projeniz insanlar tarafından planlandığı ve uygulandığı sürece , bunun hiçbir zaman gerçek olmamasıdır.
Gereklilikler ve şartnameler kalifiye mimarlar ve tasarımcılar tarafından çok ayrıntılı bir şekilde belirlenmemişse, bu durumda proje zaten yarı mamul hale getirilmediği sürece, her kenar davayı asla kapsamaz; ve o zaman bile hala hata olasılığı var.
Beklenmeyen maliyetler, bütçe aşımlarına yol açacak şekilde ortaya çıkacaktır. Bir aboneliğin süresi doldu. Bir üretici, kullanmakta olduğunuz ürüne olan desteğini bıraktı ve yenisini bulmak zorundasınız. Bir saatlik yüklenici, ayrılma tehdidi altındaki oranını yükseltti. Tüm ekibiniz greve gitti,% 10 zam ve daha fazla tatil haftası istedi.
Tarifeleri kayma. Öngörülemeyen sorunlar ortaya çıkıyor; 5 yıldan beri kullandığınız grafik bileşeni, istemcinizin hala kullandığı Windows 95 ile uyumlu değil. 64-bit Windows'ta belirsiz bir hata ciddi UI aksaklıklarına neden oluyor ve neredeyse bir hafta boyunca onu takip edip bir geçici çözüm geliştirmek için harcıyorsunuz (bu benim başıma geldi). Üst düzey geliştiriciniz bir otobüse çarptı ve işe gidip yeni bir tane eğitmelisiniz. Tahmini teslim tarihiniz her zaman yanlıştır. Her zaman.
Hofstadter Yasasını görün :
Hofstadter Yasası: Hofstadter Yasasını hesaba katsanız bile, her zaman beklediğinizden daha uzun sürer.
Çevik yöntemler tamamen maliyet, zamanlama ve kapsamda hokkabazlık ile ilgilidir. Çoğu zaman, özellikle kapsam ve programın etrafında gezinmeye odaklanırlar , bu yüzden çok iyi kullanıcı hikayeleriyle başlayıp tam sürümler yerine revizyonları planlıyorsunuz. Farklı metodolojiler farklı terminoloji kullanır ancak hepsi aynı temel öncüldür: Sık yayımlananlar ve her sürümle birlikte program ve kapsamın yeniden dengelenmesi.
Bu da herhangi bir anlamda bir (ya da istemler olmak üzere) olan bir proje ile ya da sabit sahası ya da sabit bir programa.
Eğer bir proje niteliği (maliyet / kapsam / çizelge) sabitlendi, ben söylerdim belki çevik metodolojileri için uygun olmayabilir.
Eğer iki proje nitelikleri sabittir, sonra projedir kesinlikle çevik metodolojileri için uygun değildir.
Eğer her üç nitelikleri sabittir, sonra proje muhtemelen başarısız olacak. Eğer gerçekten gönderilirse, orjinal program büyük ölçüde uyuşmazdı ya da müşteri, vaat edilen şeyi verdiğinizi düşünerek kendini kandırmayı başardı.
Bu sözleşme hala masada ise, reddetmenizi rica ediyorum. Zaten kabul etmişseniz, Tanrı ruhunuza merhamet etsin.