Kapsam dışı

 

Analistin geç dönem temel görevinin kapsamın korunması olduğuna önceki yazılarımızda değinmiştik. Aynı şekilde, kapsamı korumak için alınacak ilk ve en önemli önlemin net ve üzerinde uzlaşıya varılmış bir kapsam olduğunu da belirtmiştik. Bir önceki yazı kapsamın ifadesi için kullanılacak vizyon kapsam dokümanının içeriği hakkındaydı. Bu dokümanda yer alan "kapsam dışı" maddesinin de önemi ilgili yazıda vurgulanmıştı. Bu başlık çoğu kez yanlış anlaşılmaya yol açabildiğinden bu konuda biraz daha açıklama yapmak gerektiğini düşünüyorum.

 

Kapsam dışı gerçekten yanlış anlaşılabilir bir başlık. Doküman şablonundaki bir önceki maddenin, kapsamı belirleyen temel özellikler olduğu da göz önüne alındığında, ilgili maddede ifade edilmemiş herşey aslında kapsam dışıdır diye düşünüyor insan. Ya da başka bir bakış açısıyla, kapsamda yer almayan herşeyi sıralamanın imkansız olduğu kendiliğinden belli oluyor. O takdirde bu başlık nasıl kullanılır?

 

Bu başlığın kapsamı koruma konusundaki önemini defalarca vurguladığıma göre bunun faydasını da detaylandırmalıyım. Bu konuda iki örnek gelebiliyor insanın aklına. Bunlardan birinici müşterinin önce istediğini beyan ettiği, ardından vaz geçtiği özellikler. Dokümanın ön analiz sırasında hazırlandığını ve kapsam konusunda henüz bir mutabaka varmadığımızı aklımızda tutarak bu örneği inceleyelim.

 

Bir müşterimiz bizden kendi özel iş ihtiyaçları doğrultusunda bir yazılım talep eder. Ön analiz için yapılan ilk görüşmelerde diğer özelliklerin yanında bir de bütçeleme özelliği yer almaktadır. Bu özelliğin detaylarını sorduğumuzda sonraki toplantıda cevaplayacaklarını belirtirler, ancak sonraki toplantıda bu özellikten vazgeçerler, böylece özellik devre dışı kalır. Proje devam eder, geliştirmenin ilerleyen safhalarında müşterimiz "işte bütçeleme de burada bu şekilde çalışacak" diyerek iptal edilen bütçeleme özelliğini tanımlar ve talep eder.

 

Bu aslında gayet yaygın şekilde görülen bir durumdur ve başka projelerde de başımıza gelmektedir. Bu durumun temelinde ilgili özelliğin iptal sebebi yatmaktadır. Müşteri özelliği istemediği için iptal etmemiştir, özelliğin gerçek iptal nedeni bunu tanımlamakta güçlük çekmeleridir. Ön analiz safhasının soyut karakteri müşterinin ilgili özelliği gözünde canlandırmasına imkan vermez, anlatamadığı birşeyi istemekten çekinen müşteri özellikten vazgeçmek zorunda kalır. Geliştirmenin ilerleyen safhalarında artık çözüm şekillendiğinden ilgili özelliği tarif etmek artık çok daha kolaydır, öyleyse müşterinizin bu istemek için önünde bir engel kalmaz.

 

İşte bu tarzda bir kapsam kaymasını engellemenin yolu, bu özelliğin adı geçip de sonra müşteriniz vazgeçtiğinde ilgili özelliği kapsam dışı maddesine eklemektir. Böylece müşteri ilgili özelliği tekrar istemeye niyetlendiğinde, üzerinde mutabakata varılmış vizyon kapsam dokümanında bu özelliğin bu sürümde yapılmayacağını, yani bu projenin kapsamının dışında olduğunu ispat edebilirsiniz. Tabii daha önce değindiğimiz kapsam kayması durumlarında ifade edilen dahili zaruri bir ihtiyacı atlamadığınızdan emin olmalısınız.

 

Benzer bir diğer durum da, belli bir özelliğin sizin tarafınızdan önerilmesi, ancak tartışma sonrasında reddilmesidir. Daha sonra bu isteği karşınızda "en önemli eksik" olarak görmek istemiyorsanız baştan kapsam dışına eklemekte fayda vardır.

 

Gördüğünüz gibi doküman şablonundaki bu kapsam dışı başlığı faydalı ve gerekli bir başlıktır ve bu şekilde kullanılmalıdır.

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

2 Responses to Kapsam dışı

  1. Deniz dedi ki:

    Çok doğru! Kapsam dışı olduğu bilinip, belirtilmemiş her şey bir risk unsurudur. Bu sebeple belirtmekten zarar değil fayda gelir. Ancak şu anda karşı karşıya olduğum durumda ne yapsam bilemiyorum. Bir ihaleye teklif ile beraber verilmesi beklenen proje yönetim planı hazırlıyorum. Doğal olarak kapsam bu belgenin bir parçası. İyi bir kapsam dokümanında bulunması gereken "kapsam dışı" maddesini eklemem durumunda, teklifler değerlendirilirken bizim teklifimiz için dezavantaj oluşturur mu diye düşünüyorum. Yine de kapsam dışı maddesini ekleyeceğim. Sonuçları göreceğiz : )

  2. Yusuf dedi ki:

    Merhabalar,Scope\’un kullanıdığınız proje yönetimine bağlı olduğunu düşünüyorum.Waterfall uygularsanız böyle bir sorun ile karşı karşı kalınacağı aşikar görülüyor.Eğer Agile olarak (özellikle scrum)ilerlerseniz, Scope u,özgür bıraktığınız için daha az sorun yaşanacaktır.Hatta pratikler gösteriyor ki Scope\’un %60 -70 tamamlandığında dahi müşteri (sponsor) yapılan işe kabul ediyor ve bu bizim için yeterli diyebiliyor.Önceliği iyi belirlenmiş High Level Requirments(Product Backlog) mutabıksanız bunun dışını müşteriye out-of-scope diyebilirsiniz.Tam bir realese çıkıncaya(High Level Requirmentlar yukarıdan aşağıya önem sırasına göre tamamlanıncaya kadar) müşteriye her 2-4 hafta da birşeyler deliver ederek ilerler iseniz (sprint) scope değişikliğinde bile projeyi handle etme yetisine sahip olursunuz.IT Projeleri dinamik projeler olduğundan dolayı(dünya hızla değişiyor,iş ihtiyaçları ve buna bağlı fonsiyonel ihtiyaçalar değişken) scope\’u sabit tutmak çok sağlam ve temiz geçmiş bir projenin ardından dahi ölü doğumla sonuçlabilir.Çünkü scope\’u sabit tuttuğunuz zaman geliştirilen uygulamanın artık müşterişi için Business Value\’su siz projeyi bitirinceye kadar kalmamış olabilir.Sponsorunuza (müşterinize) giderken şu şekilde bir yaklaşımla gitmekte fayda olduğunu düşünüyorum.Sizle High Level \’da anlaştık. 2-4 hafta içinde size ilk demo larımızı yapıyor olacağız ve bu şekilde her 2-4 haftada bir sizinle demo yaparak ilerleyeceğiz.Tahminen 6-8 Demo sonra (Product Backlog\’a bakarak – 6-8 Sprint Plani yapılmış) ile kullanılabilir sürümü(Release\’i) yayınlıyor olacağız.Sprint aralarında Sponsor ile zaten yanyana çalışıyorsunuz.Projeye Go,No Go kararı verilebilir durumda olacaksınız.Genelde 2-3 sprinten sonra proje rengini verir düzeyde olacaktır.Sizle masaya bu noktadan sonra tekrar oturalım diyebilirsiniz.ilk 3 sprintin maliyeti budur projenin başında söylemelisiniz.Bu sayade hem müştreyi hemde kendinizi riske atmamış olursunuz.İyi Çalışmalar.

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