Rank: Member
Groups: Member
Üyelik Tarihi: 4/26/2008
Mesaj Sayısı: 26
Puan: 78
Nerden: Australia
|
Bu bölümde Getting Real kitabı projedeki 3 ana etkenden söz ediyor. Bunlar:
Bütçe
Piyasaya Çıkış Tarihi
Kapsam
Eğer zamanında ve bütçeyi aşmadan piyasaya bir şeyler çıkartmaya çalışıyorsak ki her projenin amacı budur, o zaman bu iki etkeni (Bütçe ve Çıkış Tarihi) sabit tutmayı öğütlüyor. Eğer belirlenen bütçe ve zaman içerisinde ortaya bir şeyler çıkmayacaksa proje kapsamının daraltılması ve sunulacak özelliklerin azaltılmasını söylüyor.
Genelde efsanevi hale gelmiş belirli bütçe, belirli zaman ve belirli kapsam ile piyasaya çıkmak hayalden öteye gitmiyor.
Kapsamı daraltmak kulağa hoş gelse de müşteriye olan bağlılığımız veya anlaşmalarla elimizin kolumuzun bağlı olduğu durumlarda problem yaratabilir. Ama yazılımı kendimiz için yazıyorsak problem yok. Kesintiye uğrattığımız özellikleri daha sonra da ekleyebiliriz.
Azalatılmış kapsamlı fakat doğru çalışan bir ürün yerine geniş kapsamlı ve bir sürü hatası olan bir yazılımı zamanında piyasaya çıkarsak firmanında müşteri gözündeki değeri düşecektir.
Tabii kapsamı daraltırken nelerin kırpılacağını nelerin kalacağını iyi kestirmek gerekiyor. Kapsam daraltıldığı halde hala hatalı bir yazılım ortaya çıkıyorsa, yazılım üretme sürecinizde yanlış bir şeyler var demektir.
Getting Real; bütçenin ve zamanın belirli, kapsamında esnek tutulmasının yararlarını şöyle sıralamış.
Öncelikleri Belirleme
Gerçekten önemli olan özellikleri ortaya çıkarmaya yardımcı oluyor. İlk sürüme nelerin gireceğini düşünmek belli bir kısıtlama yaratıyor ki bu da özelliklerin üzerinde gerçekten kafa yorulması anlamına geliyor. Ah Yandım Vah Yandım demek yerine oturup gerçekten bazı özelliklere ilk sürümde ihtiyaç var mı kafa patlatıyoruz.
Realite
İhtiyaçları doğru olarak belirleme buradaki püf noktası. 3 etkeni de sabit tutmaya çalışırsak ortaya çıkacak ürünün kalitesi de düşük olacaktır. Belki bir sürüm vereceksiniz ama bu sürüm gerçekten müşterinin önüne koymak istediğiniz bir ürün olacak mı?
Esneklik
Buradaki püf noktasıda değişebilirlik. Her şeyi fikslemek değişebilirliği zor kılıyor. Sadece kapsamı değişebilir kılmak en azından bazı seçenekler sunuyor.
Bu bölümü çevirirken kendimi salak gibi hissettim. Zira bazı kısımlar sanki sırf laf salatası gibi geldi. Uzun lafın kısası kapsamı daraltarak zamanında ve bütçeyi aşmadan tam çalışan ve hatasız bir ürün ortaya çıkarıyoruz. Fakat kestiğimiz özellikleri sonradan eklerken gene zaman ve bütçe gerekmiyor mu? Bu bölüm kendi içinde çelişti çoktan. Yorumlarınızı bekliyorum.
|
