Domain Storytelling — Lodera Vaka Çalışması IV

“After all, if users could always explain exactly what they needed, we wouldn’t need disciplines such as Product Management and Requirements Analysis.” — When What We Ask for Is Not What We Get, and What We Get Is Not What We Need (John Ferguson Smart)

Selamlar,

Önceki bölümde gereksinimlerin türetilebilmesi için domain story’lerin hazırladığı ortamı, User Stories ve User Story Mapping teknikleriyle destekleyerek gereksinimlerin ve bu gereksinimler üzerine konuşan paydaşların ifade gücünün nasıl artırılacağından bahsettik. Paydaşların gereksinimler üzerindeki yüksek ifade gücü, gereksinimleri öznel olmaktan çıkararak tartışılabilir ve değerlendirilebilir hale getirir ve tüm paydaşlar tarafından daha nesnel şekilde algılanmasını sağlar. Bir gereksinim hakkında ifade gücünüz yeterince yüksek olmadığında, bu gereksinimin yazılım sistemine taşınıp taşınmayacağına dair değerlendirmeyi eksik ya da hatalı yapabilir ve algıladığınız bu “gerçek” gereksinimi kullanıcıya sunamayabilirsiniz.

Bu bölüm, Lodera domainine ait bir alt parçanın (subdomain) anlaşılmasını sağlayan yeni bir domain story kaydı ile başlayacak; ardından User Story Mapping ile devam ederek uçtan uca bir gereksinim türetme sürecini ele alacak.

Bu amaçla, Lodera’dan Sandy ile bir araya gelerek ondan yük kabul hikayesini dinleyeceğiz.

Moderator: Merhaba Sandy, Lodera’nın yük kabul süreci nasıl çalışıyor?

Sandy (Load Acceptance Person): Merhaba, müşteri taşınmasını istediği yüke ait bilgileri, mesafeyi ve taşımayı gerçekleştirmemizi beklediği tarih aralığını belirtir.

Figure 3.18: The ‘load acceptances’ subdomain (created with egon.io)

Sandy: Sonrasında belirtilen bilgilerle kendisine bir yük kabul sözleşmesi hazırlamamı ister. Yük için bir yük kabul sözleşmesi hazırlayarak fiyatıyla birlikte müşteriye sunarım. Eğer imzalarsa, taşımayı belirtilen tarihte gerçekleştiririz.

Figure 3.19: Load acceptances, happy path — COARSE-GRAINED (created with egon.io)

Şekil 3.19, buraya kadar anlatılanları kapsar ve coarse-grained seviyede bir happy path senaryosu elde etmemizi sağlar; böylece hikayede daha da derinleşme fırsatı yakalarız.

Moderator: Sözleşme hazırlama sürecini detaylandırabilir misin?

Sandy: Elbette, müşteri için boş bir sözleşme formu alarak bu formu sözleşme numarası, yük, güzergah ve tarih aralığı bilgileriyle doldururum.

Figure 3.20: Load acceptances, happy path — FINE-GRAINED (created with egon.io)

Sandy: Daha sonra yük bilgileri, güzergah ve tarih aralığı bilgilerine göre sözleşme fiyatını hesaplarım. Hesaplama sonrasında sözleşmenin sunulması ve imzalanması süreci, daha önce bahsettiğim şekilde ilerler.

Figure 3.21: Load acceptances, happy path — FINE-GRAINED (created with egon.io)

Buraya kadar anlatılan süreçler kaydedildiğinde, fine-grained seviyedeki Şekil 3.21 ortaya çıkar.

Önceki bölümden Şekil 3.17’deki User Story Mapping ile ortaya çıkardığımız backbone’u hatırlayın. Map’in daha detaylı gereksinimler içerebilmesi için daha fine-grained domain story’ler kaydederiz; daha fine-grained story’ler, daha fine-grained gereksinimler ortaya çıkarır. Bu nedenle Şekil 3.21’deki happy path senaryosunun tersini soracak ve bunu da kaydedeceğiz.

Moderator: Müşteri sözleşme fiyatını kabul etmeyerek sözleşmeyi imzalamadığı durumda nasıl bir süreç izliyorsun?

Sandy: Bu durumda farklı bir güzergah ile sözleşme fiyatını yeniden hesaplarım. Yeni güzergah ilkinden daha uzun olacağı için, buna bağlı olarak taşıma tarihi aralığı da değişir.

Hikayenin bu bölümünü kaydederken, Şekil 3.21’deki dördüncü cümleden sonraki kısma bir cümle daha eklemek yeterli olacak ve Şekil 3.22 ortaya çıkacaktır.

Figure 3.22: Load acceptances, rejection— FINE-GRAINED (created with egon.io)

Önceki bölümde detaylandırdığımız şekilde, buraya kadar kaydettiğimiz farklı seviyelerdeki domain story’ler, Şekil 3.23’teki kite-level gereksinimlerden oluşan backbone’u ortaya çıkarır.

Figure 3.23: load acceptance backbone — kite-level requirements

Backbone’a eşleyebileceğimiz daha fine-grained seviyedeki gereksinimler ise Şekil 3.24’teki gibi ortaya çıkar.

Figure 3.24: load acceptance backbone — sea-level requirements

Sandy ile daha fazla gereksinim türetebilmek amacıyla, happy path dışındaki senaryoyu konuştuğumuz Şekil 3.22 ile birlikte ortaya çıkan map, Şekil 3.25’teki gibi olur.

Figure 3.25: sea-level requirements

Bu bölümü, bir önceki bölümle ve subtitle’da bir alıntısını yaptığımız makaleyle birlikte çalışmanız, gereksinimler konusunda yeni bir bakış açısı kazanmanızı ve nitelikli çıktılar elde etmenizi sağlayacaktır. Tüm bunlarla hedeflediğimiz şey; bir domain experti, iş analistini, iş birimini ya da size özellik anlatan herhangi birini gereksinimler konusunda sorgulayabilmeniz ve bunun bir sonucu olarak gerçekten ihtiyaç duyulan özelliklere sahip bir yazılım geliştirebilmenizi sağlamaktır.

Keyifli okumalar…