Kapsam kayması II – Değişiklik istekleri

Her projenin kapsamı kayar. Kapsamı sabit tutmaya çalışmaktansa değişimi yönetmek daha verimli sonuçlar elde etmenizi sağlayacaktır. Kapsamı korumanın birinci koşulu, iyi yürütülmüş bir analiz fazı sonucunda net olarak belirlenmiş, ifade edilmiş ve üzerinde mutabakata varılmış kapsamdır. Kapsam net değilse onu korumak da mümkün olmaz. Yine de makul sapmayı kabüllenmek ürün açısından doğru tercih olacaktır.
 
Üzerinde açıkça anlaşılmış kapsamı korumak için değişikliği yönetmek gerekir dedik. Bunun için değişikliği farklı özniteliklerine göre sınıflandıracağız:
 
1. Etki
Değişiklikler etki açısından ikiye ayrılmalıdır: asli (birincil) ve tali (ikicil). Asli değişiklik istekleri başlı başına kapsam kayması yaratan, büyük ve önemli değişikliklerdir. Tali değişiklik istekleri ne zaman ne de iş yükü ve teknik riskler açısından önem taşımayan, kolayca gerçekleştirilebilecek isteklerdir. Stabilizasyonun son aşamaları hariç tali istekleri uygulamak uygundur. Ancak bunları sayıca artması gereksinim yönetimi zaafiyetine işaret ediyor olabilir. Toplamda %10’u (işdalı ve projenize göre düzenleyin) aşmayan kapsam kayması "tampon" zaman ile karşılanmalı ve kabüllenilmelidir.
 
2. Kaynak
Değişiklikler, paydaşların isteklerine dayanabileceği gibi paydaşların müdahil olamayacağı dış sebeplerden de kaynaklanabilir. Örneğin iş kurallarındaki değişiklikler ya da yasal değişiklikler, özellikle de analiz bittikten sonra ortaya çıkıyorlarsa dış kaynaklı kabül edilmelidir. Proje paydaşlarının, özellikle müşterinin değişen istekleri ya da yanlış anlaşmalar sonucunda değişmesi gereken özellikler iç kaynaklıdır. Bu yüzden kaynak açısından değişiklikler dahili ve harici olarak ikiye ayrılır.
 
3. Zorunluluk
Belli bir özelliğin değiştirilmemesi ya da eklenmemesi ürünü kullanılamaz hale getirebilir. Zaruriyet, ürünün kullanması için vazgeçilmesi imkansız özellikleri ifade eder. Müşteriler pek çok kez bütün isteklerini vazgeçilemez olarak nitelendirebilirler ancak gerçekten vazgeçilemez özellikler çoğu kez görünenden azdır. Temel prensip olarak analiz sırasında tüm istekleri, birbirleriyle ve vizyonla çelişmediği sürece zaruri; tutarlılaştırma sırasında ise tüm istekleri keyfi olarak değerlendirmekte fayda vardır. Bu suretle zorunluluk keyfi ve zaruri olarka ikiye ayrılır.
 
Kapsamın korunması için değişiklik yönetimi kurallarını belirlemeliyiz:
  1. Tali istekleri kontrolü kaybetmeden uygulayın. Gücünüzü bunları reddetmek için tüketmeyin, diğerleri için ihtiyacınız olabilir.
  2. Asli isteklerden "zaruri harici" olanlar kontrolünüzün dışında gelişmiştir; etkisi risk yönetimi ile berteraf etmeye çalışılmalıdır, ancak son çare olarak proje planı revize edilmelidir, sonuçta kapsam kayması sizin hiçbir surette engeleyemeyeceğiniz şekilde gelişmiştir. ("elle gelen düğün bayram")
  3. "Zaruri dahili" değişiklik istekleri, olmazsa olmaz bir özelliğin yanlış anlaşıldığı veya atlandığına işarettir ki, bu analistin açık hatasına işaret eder. Değişikliği kabül ederek bedelini ödemekten başka çare yoktur. Bunu engellemenin yegane yolu olgun analiz süreci ve gelişmiş gereksinim yönetimi uygulamalarıdır.
  4. "Dahili keyfi" değişiklik istekleri, paydaşların sonrada ortaya çıkarttıkları özellik talepleri veya ürünü görmek suretiyle gelen ilham sonucu ifade ettikleri isteklerdir. Bunlar iş açısından kıymet ifade edebilirler, ancak proje açısından gereksiz risk teşkil ederler. Her şartta bir sonraki versiyonda ele alınmak üzere ertelenmelidirler.
  5. "Harici keyfi" değişiklik isteği olmaz; acil olmayan harici değişiklikler, örneğin duyurulmuş ancak birkaç yıl sonra yürürlülüğe girecek değişiklik istekleri keyfi olarak kabül edilebilir. "Dahili keyfi" gibi ele alınmalıdır. 

Kısaca, taliyi uygula, keyfi değişiklikleri ertele, harici zaruri değişiklikler için proje planını revize et, dahili zaruriyi iyi gereksinim yönetimi uygulayarak engelle ya da kabul (ve zarar) et.

Keyfi değişiklikleri ertelemek her zaman doğru yoldur. Birçok kez sonradan ortaya çıkan keyfi değişiklikleri ertelediğimiz zaman ilk günkü "heyecan verici" önemini yitirdikleri ve gözden düştüklerini gözlemledik. Hemen hemen her sistem devreye alma sonrasında bazı değişiklik istekleri ile karşılaşacaktır, keyfi değişiklik istekleri bunlarla beraber projelendirilmelidir.

Kapsamın korunmasında kapsamın tanımlanması temeli teşkil eder dedik. Bununla ilgili de söylenecek birkaç söz var ama bu da bir başka girdiye.

Bu yazı Yazılım mühendisliği içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s