Event Storming Detaylı anlatım, Temel Kavramlar, Örnek Senaryolarla SSS ve Cevapları

Event Storming'i bir aptala anlatır gibi anlatır mısın? Ne zaman ve hangi ihtiyaçla ortaya çıktı? Avantajları neler? Dezavantajları neler? Hakkındaki kitaplar, videolar, kurslar nelerdir?

Event Storming: Event Storming, bir yazılım projesini planlamanın veya bir iş problemini çözmenin hızlı ve etkili bir yolu olarak adlandırılan bir iş atölyesi tekniğidir. Bu tekniği anlamak için önce birkaç temel kavramı açıklamam gerekiyor.

Event: Bir olay, sistemin bir durumunu değiştiren bir şeydir. Örneğin, bir siparişin alınması, bir ödemenin işlenmesi gibi.

Storming: Burada "fırtına" kelimesi, yoğun bir beyin fırtınası oturumu anlamına gelir.

Bu süreçte, iş hedeflerini, iş süreçlerini ve sistem gereksinimlerini çözümlemek için bir grup insan bir araya gelir. Herkes, post-it'lerle bir duvarın üzerine "olayları" yerleştirir ve bunları çeşitli şekillerde düzenler. Bu düzenlemeler, sistemin nasıl çalışması gerektiğini anlamak ve bu işleyişi iyileştirmek için yapılır.

Ne zaman ve hangi ihtiyaçla ortaya çıktı: Event Storming, 2013'te yazılım danışmanı ve yazar Alberto Brandolini tarafından ortaya çıkarıldı. Ana hedef, karmaşık iş süreçlerini ve yazılım sistemlerini anlama ve modelleme sürecini daha hızlı, daha etkili ve daha katılımcı yapmaktı.

Avantajları:

Katılımcı: Herkesin görüşlerini ifade etmesine izin verir. Bu, genellikle yeni bakış açıları ve fikirlerin ortaya çıkmasını teşvik eder.

Hızlı: Bir iş problemini veya yazılım projesini çözümlemek için hızlı bir yöntemdir. Bu süreç genellikle birkaç saat ile birkaç gün arasında sürer.

İletişim: Herkesin aynı sayfada olmasını sağlar ve iletişim engellerini aşar.

Esneklik: Değişen ihtiyaçlara ve öğrenilen yeni bilgilere hızlı bir şekilde yanıt verebilir.

Dezavantajları:

Struktür eksikliği: Olayların belirli bir sıralaması yoktur, bu da bazen karışıklığa neden olabilir.

Herkesin katılımını gerektirir: Bu sürecin etkili olabilmesi için, tüm ekip üyelerinin aktif olarak katılması gerekir. Herkesin katılımını sağlamak bazen zor olabilir.

Sonuçların işlenmesi: Event Storming sonrasında genellikle çok sayıda bilgi ve fikir çıkar, bu bilgi ve fikirlerin işlenmesi ve uygulanması zor olabilir.

Hakkındaki kitaplar, videolar, kurslar: Event Storming hakkında en yaygın ve bilinen kaynak, bu konsepti yaratan kişi olan Alberto Brandolini'nin kitabı "Introducing EventStorming - An act of Deliberate Collective Learning"dir. YouTube'da ve diğer video paylaşım sitelerinde, Event Storming hakkında çok sayıda eğitici video bulabilirsiniz. Ayrıca Udemy, Coursera gibi online kurs platformlarında Event Storming üzerine kurslar da bulabilirsiniz.

Event Storming, genellikle büyük bir duvar veya beyaz tahta üzerine renkli yapışkan notların yerleştirilmesi şeklinde uygulanır. Olaylar, başından sonuna kadar bir iş sürecinin veya yazılımın işleyişini temsil etmek üzere kronolojik bir sıra ile düzenlenir. Ayrıca başka renkli yapışkan notlar kullanarak, iş süreçlerini etkileyen diğer faktörler belirtilebilir. Örneğin, kullanıcıların hangi eylemleri gerçekleştireceği, hangi dış etkenlerin iş sürecine etki edebileceği gibi.

Bu süreç aşağıdaki adımlardan oluşabilir:

Domain Events Belirleme: İlk adım genellikle iş sürecindeki önemli olayları belirlemektir. Örneğin, bir e-ticaret sitesi için "ürün eklenir", "ürün sepete atılır", "ödeme yapılır" gibi olaylar olabilir.

Olayları Düzenleme: Belirlenen olaylar, genellikle kronolojik bir sıra ile düzenlenir. Bu, tüm ekibin iş sürecinin nasıl işlediğini anlamasına yardımcı olur.

Aktörler ve Komutları Belirleme: İş sürecine dahil olan aktörler (kullanıcılar, sistemler vb.) ve bu aktörlerin gerçekleştirdiği eylemler (komutlar) belirlenir. Örneğin, bir müşteri "ürün sepete at" komutunu verebilir.

Kısıtlamalar ve İstisnaları Belirleme: İş sürecindeki kısıtlamalar ve istisnalar da belirlenir. Örneğin, bir ürünün stokta olmaması durumunda ne olacağı gibi.

Modeli İnceleme ve İyileştirme: Son olarak, tüm ekip oluşturulan modeli gözden geçirir ve geliştirmeler yapar. Bu, genellikle model üzerinde tartışmayı ve farklı senaryoları keşfetmeyi içerir.

Event Storming, karmaşık iş süreçlerini ve yazılım projelerini anlamak için hızlı ve etkili bir yöntem sağlar. Bu süreç, genellikle yeni bakış açıları ve fikirlerin ortaya çıkmasını teşvik eder ve tüm ekibin aynı sayfada olmasını sağlar.

Ancak, Event Storming'in bazı dezavantajları da vardır. Örneğin, bu süreç genellikle tüm ekip üyelerinin aktif katılımını gerektirir, bu da her zaman mümkün olmayabilir. Ayrıca, süreç sonunda genellikle çok fazla bilgi ve fikir ortaya çıkar, bu bilgilerin işlenmesi ve uygulanması zor olabilir.

Eğer daha fazla detaylı bilgi almak isterseniz, Alberto Brandolini'nin "Introducing EventStorming - An act of Deliberate Collective Learning" kitabını okumanızı öneririm. Bu kitap, Event Storming konseptini detaylı bir şekilde anlatır ve bu süreci nasıl uygulayacağınıza dair pratik öneriler sunar. Ayrıca, YouTube ve diğer video paylaşım sitelerinde Event Storming hakkında birçok eğitici video bulabilirsiniz.

Event Storming Facilitator 

Event Storming süreci genellikle bir facilitator tarafından yönlendirilir. Facilitator'un rolü, süreci yönetmek ve herkesin aktif olarak katılımını sağlamaktır. Facilitator, tartışmaları yönlendirir, çatışmaları çözer ve sürecin düzgün ve etkili bir şekilde ilerlemesini sağlar.

Event Storming, iş süreçlerini anlamak ve iyileştirmek için mükemmel bir tekniktir. Sadece iş süreçlerini anlamakla kalmaz, aynı zamanda farklı ekip üyeleri arasında daha iyi bir iletişim ve anlayış oluşturur. Bu, daha etkili çözümler ve daha başarılı projeler oluşturabilir.

Trendyol Tech DDD Days - Event Storming

Event Storming süreci ile ilgili daha fazla detay vererek başlayacağım.

Event Storming Sürecinde Dikkat Edilmesi Gerekenler

Tüm Katılımcıların Aktif Olması: İyi bir Event Storming oturumu, herkesin aktif ve etkin katılımını gerektirir. Tüm katılımcılar, kendi bakış açılarını, bilgilerini ve deneyimlerini paylaşmalıdır.

Geri Bildirim Döngüsünün Hızlı Olması: Event Storming, hızlı geri bildirim döngülerine dayanır. Bu, katılımcıların fikirlerini paylaşmalarını, geri bildirim alabilmelerini ve hızlı bir şekilde modeli iterasyon yapabilmelerini sağlar.

Güvenli Bir Ortam Oluşturmak: Event Storming, tartışmaların ve fikir paylaşımının olabileceği güvenli bir ortam gerektirir. Katılımcıların fikirlerini özgürce ifade edebilmeleri, geri bildirim alabilmeleri ve tartışmalara katılabilmeleri için bir güven ortamı oluşturulmalıdır.

Event Storming ve Domain-Driven Design (DDD)

Event Storming, DDD ile birlikte kullanıldığında özellikle güçlüdür. DDD, yazılımı iş süreçlerine daha yakından hizmet etmesi için tasarlamaya odaklanır ve bu süreçlerdeki olayları ve iş kurallarını belirlemek için Event Storming kullanabilir.

Bir DDD yaklaşımı içinde, Event Storming genellikle sürecin ilk adımıdır ve ardından DDD'nin diğer bölümleri izler:

Event Storming: Bu, iş süreçlerini ve olayları anlama aşamasıdır. Ekip, sürecin genel resmini çizer ve süreç boyunca neyin gerçekleştiğini anlar.

Domain Modelleme: Event Storming'ın ardından, ekip domain modelini oluşturur. Bu model, iş süreçlerinin ve kurallarının bir görselleştirmesidir.

Software Tasarımı: En sonunda, ekip yazılımın nasıl tasarlanacağını belirler. Bu tasarım, Event Storming ve domain modelleme aşamalarında elde edilen bilgilere dayanır.

Event Storming, genellikle karmaşık iş süreçlerini anlama ve modelleme aşamasında kullanılan bir tekniktir. İyi uygulandığında, bu sürecin sonunda ekip, iş süreçlerini ve bu süreçleri daha etkili hale getirmek için hangi adımları atması gerektiğini daha iyi anlayabilir.

Event Storming, doğru şekilde yapıldığında, bir organizasyonun iş süreçlerini ve yazılım sistemlerini iyileştirmek için değerli bir araç olabilir. İşte bazı ilave notlar:

İyi Bir Event Storming Oturumu İçin İpuçları

Herkesin Fikirlerini İfade Edebilmesi İçin Güvenli Bir Ortam Yaratın: Katılımcıların düşüncelerini, endişelerini ve fikirlerini özgürce ifade edebileceği bir ortam sağlamak çok önemlidir. Bu, insanların çekinmeden fikirlerini sunmalarına ve yaratıcı çözümler bulmalarına yardımcı olur.

Facilitator'un Rolünü Anlayın: Facilitator'un rolü, süreci yönetmek ve katılımcıların etkin bir şekilde katılımını sağlamaktır. Facilitator, tartışmaları yönlendirebilir, çatışmaları çözebilir ve sürecin etkin ve düzgün bir şekilde ilerlemesini sağlar.

Geri Bildirim Döngülerini Hızlı Tutun: Event Storming'da geri bildirim döngülerinin hızlı olması önemlidir. Bu, insanların hızlı bir şekilde fikirlerini sunmalarını ve geri bildirim alabilmelerini sağlar, böylece sürecin hızlı bir şekilde ilerlemesine yardımcı olur.

Modeli Görsel Hale Getirin: Event Storming süreci, iş süreçlerini görsel bir şekilde temsil etme üzerine kuruludur. Bu, sürecin nasıl çalıştığını ve hangi adımların atılması gerektiğini daha iyi anlamayı sağlar.

Event Storming ve Agile/Scrum

Event Storming ayrıca Agile ve Scrum metodolojileri ile de mükemmel bir şekilde entegre olabilir. Event Storming, iş süreçlerini ve gereksinimlerini anlamaya yardımcı olur, böylece ekipler Agile veya Scrum süreçlerinde bu bilgileri kullanabilir.

Özellikle, Event Storming genellikle bir proje başlatıldığında veya yeni bir özellik eklendiğinde kullanılır. Bu, ekiplerin iş süreçlerini anlamalarını ve hangi adımların atılması gerektiğini belirlemelerini sağlar.

Event Storming, iş gereksinimlerini ve süreçlerini belirleme ve anlama konusunda çok değerli bir araç olabilir. İyi bir Event Storming oturumu, daha etkili bir iş süreci ve daha başarılı bir yazılım projesi oluşturmanın ilk adımı olabilir.

Event Storming'deki Terimler ve Kavramları Anlatır mısın?

Evet, Event Storming sürecinde bu terimler ve kavramlar çok önemli. Her birini detaylarıyla açıklayacağım:

Eventler (Olaylar): Bir Event Storming oturumunda, olaylar genellikle turuncu renkli notlarla gösterilir. Bir olay, sistemde veya iş sürecinde belirli bir durumu değiştiren ve belirli bir sonuç yaratan bir şeyi temsil eder. Örneğin, bir online alışveriş sürecinde, "ürün sepete eklendi" bir olay olabilir.

Aktörler: Aktörler, bir olayı tetikleyen veya o olaya yanıt veren kişiler veya sistemlerdir. Bu genellikle insan kullanıcılar, ancak diğer sistemler veya otomatik işlemler de olabilir. Aktörler genellikle notların üzerinde veya altında isimleri ile belirtilir.

Dış Sistemler: Dış sistemler, bir olayı tetikleyen veya o olaya yanıt veren sistemlerdir. Bu genellikle başka bir hizmet, uygulama veya platform olabilir. Dış sistemler genellikle bir olayın yanında veya üzerinde belirtilir ve bunlar, sürecin bir parçası olan ancak kontrolümüz dışında olan sistemleri temsil eder.

Koşullar: Koşullar, belirli bir olayın gerçekleşmesi için gereken özel durumları veya gereksinimleri temsil eder. Örneğin, bir online alışveriş sürecinde, "ürünün stokta olması" bir koşul olabilir. Koşullar genellikle olayları etkileyen veya onları sınırlayan faktörler olarak düşünülebilir ve genellikle sarı veya yeşil notlarla gösterilir.

Komutlar (Commands): Komutlar, bir olayı tetikleyen eylemlerdir. Genellikle, bir aktörün veya dış sistemlerin bir olayı başlatmak için gerçekleştirdiği bir eylemi temsil ederler. Komutlar genellikle mavi notlarla temsil edilir.

Aggregates: Bu, DDD (Domain-Driven Design) tarafından tanımlanan bir kavramdır ve genellikle bir veya daha fazla olayın bir araya geldiği ve bir bütün olarak işlendiği birimleri temsil eder. Aggregates genellikle farklı renkte notlarla belirtilir ve bu, genellikle iş sürecindeki önemli adımları ve birimleri temsil eder.

Policies: Policies, belirli bir olaya yanıt olarak ne olması gerektiğini belirleyen kuralları temsil eder. Genellikle bir olayın ve sonuçlarının nasıl işlenmesi gerektiğine dair iş kurallarını temsil ederler. Politikalar genellikle yeşil notlarla belirtilir.

Read Models: Read models, bir olayın sonucunda oluşturulan veriyi temsil eder. Genellikle bir olayın sonucunda oluşturulan ve diğer olayları veya süreçleri etkileyen veri veya durumları temsil ederler.

Bu terimler ve kavramlar, Event Storming sürecinde belirli iş süreçlerini ve gereksinimlerini modelleme ve anlama yardımcı olur. Tüm bu kavramlar bir araya geldiğinde, bir iş sürecinin nasıl işlediği ve nasıl iyileştirilebileceği konusunda daha derin bir anlayış sağlarlar. Bu, projenin başarılı bir şekilde yönetilmesi ve uygulanması için çok değerli olabilir.

Elbette, devam ediyorum. Event Storming sürecinde belirli iş süreçlerini ve gereksinimlerini anlama ve modelleme konusunda daha fazla yardımcı olabilecek birkaç başka kavram ve terim daha vardır:

Bounded Contexts: Bounded Context, Domain-Driven Design (DDD) kavramıdır ve belirli bir modelin geçerli olduğu veya anlamlı olduğu sistem veya iş sürecinin belirli bir bölümünü temsil eder. Her Bounded Context kendi modellerine, diline ve iş kurallarına sahip olabilir. Bounded Context'ler genellikle büyük bir kağıt veya pano üzerinde ayrı bölümler olarak gösterilir.

Timeline: Event Storming'da zaman çizelgesi önemli bir rol oynar. Olaylar genellikle ne zaman gerçekleştiğini gösteren bir zaman çizelgesi üzerinde düzenlenir. Bu, sürecin nasıl geliştiğini anlamayı ve olayların birbiriyle nasıl etkileşimde olduğunu görmeyi sağlar.

Hotspots: Hotspots, bir modelde belirsizlik veya çatışma olan alanları temsil eder. Bunlar, bir olayın nasıl gerçekleştiği veya bir komutun nasıl işlendiği hakkında belirsizlik veya anlaşmazlık olduğunda genellikle ortaya çıkar. Hotspots, genellikle kırmızı notlarla gösterilir ve ekip tarafından daha fazla tartışılması veya çözülmesi gereken alanları işaretler.

Event Storming süreci, karmaşık iş süreçlerini anlama ve modelleme konusunda çok değerli bir araç olabilir. Bu terimler ve kavramlar, sürecin nasıl işlediğini ve nasıl geliştirilebileceğini daha iyi anlamaya yardımcı olur. Bu anlayış, daha başarılı bir proje yönetimi ve uygulaması için çok önemlidir.

Event Storming ile yazılım nasıl daha kolay hale gelir?

Event Storming, yazılım geliştirme sürecini birkaç farklı şekilde daha kolay ve daha etkili hale getirir:

İş Süreçlerini Anlama: Event Storming, bir iş sürecinin nasıl işlediğini anlamayı sağlar. Bu, yazılım geliştirme ekibinin hangi özellikleri geliştirmesi gerektiğini ve hangi işlevlerin en önemli olduğunu belirlemesine yardımcı olur.

Karmaşıklığı Yönetme: İş süreçleri genellikle karmaşıktır ve birçok farklı faktörü içerir. Event Storming, bu karmaşıklığı yönetmeyi ve anlamayı sağlar. Bu, yazılım geliştirme ekibinin hangi alanlara odaklanması gerektiğini belirlemesine yardımcı olur.

İletişim ve İşbirliğini Geliştirme: Event Storming, teknik ve iş ekipleri arasında etkili bir iletişim ve işbirliği oluşturur. Bu, herkesin aynı sayfada olmasını sağlar ve projenin daha hızlı ve daha etkili bir şekilde ilerlemesine yardımcı olur.

Sorunları ve Fırsatları Belirleme: Event Storming, belirsizlikleri, çatışmaları ve fırsatları belirlemeyi sağlar. Bu, yazılım geliştirme ekibinin bu sorunları çözmek için stratejiler belirlemesine ve fırsatları değerlendirmesine yardımcı olur.

Yazılım Tasarımına Yön Verme: Event Storming, Domain-Driven Design (DDD) ve mikroservis mimarileri gibi yazılım tasarım yaklaşımlarıyla mükemmel bir şekilde entegre olur. Bu, daha sağlam ve ölçeklenebilir yazılım çözümleri oluşturmayı sağlar.

Event Storming süreci sadece yazılım geliştirmeyi daha kolay hale getirmekle kalmaz, aynı zamanda yazılımın kalitesini ve uyumluluğunu da artırır:

Riskleri Azaltma: Event Storming, yazılım geliştirme sürecindeki riskleri erken bir aşamada belirlemeye yardımcı olur. Bu, problemleri daha önce tespit etmeyi ve bunları daha az maliyetle çözmeyi mümkün kılar.

Test Stratejileri Geliştirme: Yazılımın doğru bir şekilde işlediğini doğrulamak için testlerin ne zaman ve nasıl gerçekleştirileceğini belirleme konusunda yardımcı olur. Olayların belirlendiği ve modellendiği bu görsel süreç, hangi durumların test edilmesi gerektiğini belirlemeyi kolaylaştırır.

Kullanıcı Deneyimini İyileştirme: Event Storming, kullanıcı deneyiminin merkezi bir odak noktası olmasını sağlar. Olaylar, genellikle kullanıcının perspektifinden modellenir ve bu, yazılım geliştirme ekibinin kullanıcıların gerçekten ne istediğini ve ihtiyaçlarını anlamasına yardımcı olur.

Dökümantasyon Oluşturma: Event Storming oturumları, aynı zamanda iş süreçlerinin ve yazılımın kapsamlı bir dökümantasyonunu oluşturur. Bu, yeni ekip üyelerinin hızlı bir şekilde ayağa kalkmasına yardımcı olabilir ve yazılımın bakımını ve güncellenmesini kolaylaştırabilir.

Sonuç olarak, Event Storming, yazılım geliştirme sürecini sadece kolaylaştırmakla kalmaz, aynı zamanda daha etkili, uyumlu ve kullanıcı odaklı yazılım çözümleri oluşturmayı da sağlar.

Event Storming SSS ve örnek senaryolarla Cevapları

Event Storming ile ilgili sıkça sorulan sorular ve örnek senaryolar şunlardır:

Soru 1: Event Storming oturumlarını kimler düzenlemeli?

Cevap: Genellikle bir iş analisti veya bir scrum master gibi bir rol üstlenen bir facilitator tarafından düzenlenir. Ancak, herkes bu süreci yönetebilir. Oturuma katılan kişiler genellikle yazılım geliştiriciler, ürün yöneticileri, iş analistleri, tasarımcılar ve diğer ilgili paydaşlardır.

Örnek Senaryo: Bir e-ticaret platformunu geliştiren bir yazılım geliştirme ekibi, alışveriş deneyimini ve işlem sürecini iyileştirmek için bir Event Storming oturumu düzenleyebilir.

Soru 2: Event Storming oturumlarının süresi ne kadar olmalı?

Cevap: Oturumların süresi genellikle sürecin karmaşıklığına ve katılımcıların sayısına bağlıdır. Bir oturum birkaç saat sürebilir veya daha karmaşık süreçler için birkaç gün boyunca sürebilir.

Örnek Senaryo: Bir bankacılık yazılımını geliştiren bir ekip, karmaşık bir kredi onay sürecini modellemek için birkaç günlük bir Event Storming oturumu düzenleyebilir.

Soru 3: Event Storming sadece yazılım geliştirme için mi kullanılır?

Cevap: Hayır, Event Storming sadece yazılım geliştirme için değil, aynı zamanda iş süreçlerini anlama ve iyileştirme, proje planlama ve hatta eğitim amaçları için de kullanılabilir.

Örnek Senaryo: Bir lojistik şirketi, kargo teslimat sürecini analiz etmek ve iyileştirmek için bir Event Storming oturumu düzenleyebilir.

Soru 4: Event Storming oturumları nerelerde gerçekleştirilir?

Cevap: Event Storming oturumları genellikle büyük bir oda veya toplantı alanında gerçekleştirilir. Ancak, çevrimiçi araçlar kullanarak sanal olarak da yapılabilir.

Örnek Senaryo: Bir ekip, dünya çapında dağıtılmış ekip üyeleriyle birlikte çalışmak için çevrimiçi bir beyaz tahta aracı kullanarak bir Event Storming oturumu düzenleyebilir.

Soru 5: Event Storming süreci ne zaman tamamlanır?

Cevap: Event Storming süreci genellikle, tüm olayların, komutların ve diğer öğelerin belirlendiği ve modelin tüm katılımcılar tarafından anlaşıldığı ve kabul edildiği zaman tamamlanır.

Örnek Senaryo: Bir sağlık hizmetleri yazılımını geliştiren bir ekip, hasta kaydı oluşturma sürecini modelleyen ve onaylayan bir Event Storming oturumu düzenleyebilir.

Soru 6: Event Storming, sadece büyük ve karmaşık projeler için mi uygundur?

Cevap: Hayır, Event Storming, büyük ve karmaşık projelerin yanı sıra, küçük ve basit projeler için de uygundur. Aslında, daha küçük projelerde bile, bu süreç yazılım geliştirme ekibinin iş süreçlerini daha iyi anlamasına ve etkili bir şekilde modellenmesine yardımcı olabilir.

Örnek Senaryo: Küçük bir startup, basit bir kullanıcı kayıt ve oturum açma işlevini modellemek için Event Storming oturumu düzenleyebilir.

Soru 7: Event Storming oturumu sonunda hangi çıktıları beklemeliyim?

Cevap: Event Storming oturumu sonunda, genellikle iş süreçlerini temsil eden bir model elde edersiniz. Bu model, olayları, komutları, aktörleri, dış sistemleri, koşulları ve diğer öğeleri içerebilir. Ayrıca, belirsizlikleri, çatışmaları ve fırsatları belirleyebileceğiniz Hotspotsları da içerebilir.

Örnek Senaryo: Bir oyun geliştirme ekibi, oyunun ilerlemesi ve oyun içi satın alımlar gibi oyun mekaniklerini modellemek için bir Event Storming oturumu düzenleyebilir.

Soru 8: Event Storming ve Domain-Driven Design (DDD) arasındaki ilişki nedir?

Cevap: Event Storming ve Domain-Driven Design (DDD), birbirleriyle yakından ilişkilidir. Event Storming, bir iş sürecinin veya sistemlerin nasıl işlediğini anlamak için kullanılır, bu da DDD'nin çekirdek bileşenlerinden biri olan Bounded Contexts'in tanımlanmasına yardımcı olur.

Örnek Senaryo: Bir otomasyon yazılımı geliştirme ekibi, belirli otomasyon görevlerini ve bu görevlerin nasıl yönetildiğini anlamak için bir Event Storming oturumu düzenleyebilir. Bu bilgi, daha sonra DDD ile uyumlu bir şekilde yazılımın modellenmesine yardımcı olabilir.

Bu örnekler ve cevaplar, Event Storming'in ne olduğunu ve nasıl uygulanabileceğini daha iyi anlamanıza yardımcı olabilir. Bu sürecin esnekliği, hemen hemen her türden proje ve iş sürecine uygulanabilmesini sağlar.

Soru 9: Event Storming, hangi yazılım geliştirme metodolojileriyle uyumludur?

Cevap: Event Storming, çeşitli yazılım geliştirme metodolojileriyle uyumludur. Çünkü esasen bir anlayış ve modelleme tekniğidir. Agile, Scrum, Kanban veya Waterfall gibi metodolojilerle kullanılabilir. Ancak genellikle Agile ve Domain-Driven Design (DDD) metodolojileriyle en iyi sonuçlar verir.

Örnek Senaryo: Bir Scrum takımı, Sprint planlama toplantısına hazırlanmak için bir Event Storming oturumu düzenleyebilir. Bu, ekibin gelecek Sprint için hangi özelliklerin geliştirilmesi gerektiğini anlamasına yardımcı olabilir.

Soru 10: Event Storming'in sınırlamaları veya zorlukları nelerdir?

Cevap: Event Storming, tüm katılımcıların aktif olarak katılımını gerektirir, bu da bazen zor olabilir. Ayrıca, tüm iş süreçlerinin anlaşılması ve modellemesi zaman alabilir. Bu süreç ayrıca bir facilitatorun rehberliğini gerektirir ve bu kişi genellikle deneyimli ve eğitimli olmalıdır.

Örnek Senaryo: Büyük ve karmaşık bir iş sürecini modellemeye çalışan bir ekip, sürecin tüm yönlerini kapsamak için birden fazla Event Storming oturumu düzenlemek zorunda kalabilir.

Soru 11: Event Storming ve User Story Mapping arasındaki fark nedir?

Cevap: Her ikisi de kullanıcı deneyimini ve iş süreçlerini anlamaya ve modellemeye yardımcı olan tekniklerdir. Ancak, Event Storming genellikle daha detaylıdır ve olayları, komutları, durumları ve diğer öğeleri içerir. Öte yandan, User Story Mapping genellikle kullanıcı deneyimini ve işlevselliği anlamaya odaklanır.

Örnek Senaryo: Bir mobil uygulama geliştirme ekibi, kullanıcıların uygulamayı nasıl kullanacağını anlamak için User Story Mapping tekniğini kullanabilir ve ardından bu süreci daha detaylı bir şekilde modellemek için Event Storming oturumu düzenleyebilir.

Soru 12: Event Storming ve Business Process Modeling (BPM) arasında ne gibi farklar var?

Cevap: Her iki teknik de iş süreçlerinin anlaşılması ve modellemesi için kullanılır, ancak yaklaşımları ve sonuçları farklıdır. BPM genellikle daha biçimsel bir yaklaşıma sahipken ve çoğunlukla önceden belirlenmiş sembollerle grafiksel diyagramlar oluştururken, Event Storming daha esnek ve işbirlikçi bir yaklaşımdır ve tüm katılımcıların sürece aktif katılımını teşvik eder.

Örnek Senaryo: Bir sigorta şirketi, iş süreçlerini iyileştirmek için BPM'yi kullanabilir, daha sonra aynı süreçleri daha ayrıntılı bir şekilde anlamak ve modellemek için Event Storming oturumu düzenleyebilir.

Soru 13: Bir Event Storming oturumunu nasıl değerlendiririm?

Cevap: Event Storming oturumunun değerlendirmesi genellikle modelin kalitesi ve detay seviyesi, katılımcıların katılımı ve sürecin ne kadar iyi anlaşıldığına dayanır. Ayrıca, oturumdan çıkan aksiyon öğeleri ve sürecin iyileştirilmesi için belirlenen fırsatlar da değerlendirilebilir.

Örnek Senaryo: Bir yazılım geliştirme ekibi, yeni bir özellik geliştirme sürecini modellemek için bir Event Storming oturumu düzenleyebilir. Oturumun sonunda, ekibin modeli ne kadar iyi anladığını ve ne kadar detaylı olduğunu değerlendirebilirler.

Soru 14: Event Storming sadece yazılım geliştirme ekibine mi yarar sağlar?

Cevap: Hayır, Event Storming sadece yazılım geliştirme ekibi için değil, aynı zamanda iş analistleri, ürün sahipleri, proje yöneticileri ve diğer ilgili paydaşlar için de yararlıdır. İş süreçlerini daha iyi anlamak ve modellemek, daha etkili kararlar almak için gereklidir.

Örnek Senaryo: Bir ürün yöneticisi, ürünün gelecek versiyonları için özelliklerin ne olacağını belirlemek için bir Event Storming oturumu düzenleyebilir. Bu, ürünün yol haritasını oluşturmak için kullanılabilir.

Soru 15: Event Storming oturumlarının süresi ne olmalıdır?

Cevap: Event Storming oturumlarının süresi genellikle katılımcıların sayısına, sürecin karmaşıklığına ve tartışılacak konuların miktarına bağlıdır. Ancak genellikle birkaç saat ile birkaç gün arasında değişir. Çok büyük ve karmaşık projelerde, oturumlar birden fazla güne yayılabilir.

Örnek Senaryo: Bir e-ticaret platformu geliştiren bir yazılım ekibi, alışveriş sepeti özelliğini modellemek için bir Event Storming oturumu düzenler. Bu oturum, alışveriş sepeti özelliğinin nispeten basit olması nedeniyle birkaç saat sürebilir.

Soru 16: Event Storming oturumlarını kimler düzenlemeli?

Cevap: Event Storming oturumlarını herkes düzenleyebilir. Ancak, genellikle bir proje yöneticisi, ürün sahibi, iş analisti veya deneyimli bir yazılım geliştirici tarafından düzenlenir. Önemli olan, oturumu düzenleyen kişinin süreci anlaması, gerektiğinde yönlendirmesi ve tüm katılımcıların aktif olarak katılımını teşvik etmesidir.

Örnek Senaryo: Bir bankacılık yazılımı geliştiren bir ekip, bir banka havalesi özelliğini modellemek için bir Event Storming oturumu düzenler. Bu oturum, iş analisti tarafından düzenlenebilir.

Soru 17: Event Storming oturumları, sadece yazılım geliştirme projelerinin başında mı düzenlenmelidir?

Cevap: Hayır, Event Storming oturumları, projenin her aşamasında düzenlenebilir. Projenin başında, iş gereksinimlerini anlamak ve sistem tasarımını planlamak için kullanılırken, projenin ilerleyen aşamalarında, belirsizlikleri gidermek, sorunları çözmek veya yeni özellikleri planlamak için kullanılabilir.

Örnek Senaryo: Bir takım, bir projenin ortasında yeni bir özellik eklendiğinde, bu yeni özelliği anlamak ve modellemek için bir Event Storming oturumu düzenleyebilir. Bu, ekibin yeni özelliği nasıl geliştireceğini anlamasına yardımcı olabilir.

Tabii ki, daha fazla Event Storming ile ilgili sıkça sorulan sorular ve örnek senaryolarla devam edelim:

Soru 18: Event Storming oturumları uzaktan da yapılabilir mi?

Cevap: Evet, Event Storming oturumları uzaktan da yapılabilir. Bu durumda genellikle dijital beyaz tahta araçları ve video konferans uygulamaları kullanılır. Ancak, bu tür bir oturumun etkili olabilmesi için katılımcıların aktif katılımını sağlamak ve herkesin sürece dahil olduğundan emin olmak çok önemlidir.

Örnek Senaryo: Bir yazılım ekibi, farklı lokasyonlarda çalışan üyeleriyle bir Event Storming oturumu düzenlemek isteyebilir. Bu durumda, dijital bir beyaz tahta uygulaması kullanabilirler ve oturumu bir video konferans üzerinden gerçekleştirebilirler.

Soru 19: Event Storming'de hangi renkler kullanılır ve bu renklerin anlamları nelerdir?

Cevap: Event Storming'de kullanılan renklerin genel bir standardı yoktur ve bu renkler genellikle oturumu düzenleyen ekibin tercihine bağlıdır. Ancak genellikle, olaylar (events) için turuncu, komutlar (commands) için mavi, dışarıdaki sistemler (external systems) için pembe ve koşullar (conditions) için yeşil gibi renkler kullanılır.

Örnek Senaryo: Bir Event Storming oturumu düzenleyen ekip, online alışveriş sürecini modellemek için bir dizi renkli yapışkan not kullanabilir. Bu yapışkan notların her biri, alışveriş sürecinin farklı yönlerini temsil eder.

Soru 20: Event Storming'de hangi tür sorunlar çözülür?

Cevap: Event Storming, çeşitli türdeki sorunları çözmek için kullanılabilir. Bunlar arasında iş süreçlerinin karmaşıklığı, iş ve teknoloji ekipleri arasındaki iletişim kopuklukları, kullanıcıların ve müşterilerin gerçek ihtiyaçlarının anlaşılmaması ve iş gereksinimlerinin net bir şekilde tanımlanmaması gibi sorunlar bulunur.

Örnek Senaryo: Bir sağlık hizmetleri şirketi, hastaların randevu alma sürecini anlamak ve iyileştirmek için bir Event Storming oturumu düzenleyebilir. Bu, iş sürecinin daha etkili ve verimli hale gelmesine yardımcı olabilir.

Tabii ki, Event Storming ile ilgili daha fazla sıkça sorulan sorular ve örnek senaryolarla devam edelim:

Soru 21: Event Storming ile hangi tür verilerin elde edilmesi beklenir?

Cevap: Event Storming oturumları sonucunda, iş süreçlerini ve sistemleri temsil eden bir dizi olay, komut, aktör ve diğer öğelerin yanı sıra, belirsizliklerin, çatışmaların ve fırsatların belirlenmesi beklenir. Ayrıca, modelin tamamlanmasının ardından, sürecin daha da geliştirilmesi için aksiyon öğeleri veya iyileştirme fırsatları da elde edilebilir.

Örnek Senaryo: Bir e-ticaret platformunu geliştiren bir yazılım ekibi, bir Event Storming oturumu sonrasında, kullanıcıların ürünleri sepete eklemesi ve ödeme yapması gibi süreçleri temsil eden bir dizi olay ve komut elde edebilir. Ayrıca, kullanıcı deneyimini iyileştirmek için önerilen aksiyon öğeleri de elde edilebilir.

Soru 22: Event Storming oturumları sadece başlangıç aşamasında mı yapılmalıdır?

Cevap: Event Storming oturumları sadece başlangıç aşamasında değil, projenin farklı aşamalarında da yapılabilir. Başlangıçta iş gereksinimlerini anlamak ve tasarım sürecini planlamak için kullanılabilirken, projenin ilerleyen aşamalarında yeni özelliklerin veya değişikliklerin analiz edilmesi ve modellemesi için de kullanılabilir.

Örnek Senaryo: Bir yazılım geliştirme ekibi, bir mevcut projenin yeni bir özelliğini eklemek için bir Event Storming oturumu düzenleyebilir. Bu, ekibin özelliği daha iyi anlamasına ve geliştirmesine yardımcı olabilir.

Soru 23: Event Storming oturumu sonrası model nasıl kullanılır?

Cevap: Event Storming oturumu sonucunda elde edilen model, yazılım geliştirme sürecinde rehberlik etmek için kullanılabilir. Model, tasarım kararlarını desteklemek, gereksinimleri netleştirmek, test senaryolarını oluşturmak ve hatta dökümantasyon oluşturmak gibi farklı amaçlar için kullanılabilir.

Örnek Senaryo: Bir yazılım ekibi, bir Event Storming oturumu sonrasında oluşturulan modeli, kod geliştirme sürecinde rehber olarak kullanabilir. Model, geliştiricilerin sistemdeki olayları, komutları ve iş süreçlerini daha iyi anlamalarına yardımcı olabilir.

Soru 24: Event Storming oturumlarına nasıl katılım sağlanır?

Cevap: Event Storming oturumlarına katılım, ilgili paydaşların aktif bir şekilde dahil olmasıyla sağlanır. Ekip üyeleri, iş analistleri, yazılım geliştiriciler, ürün sahipleri ve diğer ilgili paydaşlar oturuma katılmalı ve görüşlerini, bilgilerini ve perspektiflerini paylaşmalıdır.

Örnek Senaryo: Bir proje yöneticisi, bir Event Storming oturumu düzenlemek için ilgili paydaşları davet eder ve her bir katılımcının sürece aktif olarak katılmasını sağlar. Bu, farklı bakış açılarının temsil edildiği ve katılımcıların bilgi ve deneyimlerini paylaştığı verimli bir oturum sağlar.

Domain stroytelling'i detaylı anlatır mısın? Ne zaman ve ne amaçla ortaya çıktı? Neleri çözüyor? Zorlukları neler? Avantajları ve dezavatajları neler? Hangi şirketler kullanıyor? Kullanırken izlenen yöntemler neler?

Domain storytelling, bir konunun anlaşılmasını sağlamak için hikaye anlatma tekniklerini kullanmayı içeren bir yaklaşımdır. Birçok işletme, bu teknikleri kullanarak müşterileri, hissedarları veya çalışanları ile iletişim kurar. Yani, bir şirketin bir ürününün, hizmetinin veya stratejisinin ne olduğunu anlatmak için bir hikaye oluşturmasını ve bu hikayeyi paylaşmasını içerir.

Domain Storytelling • Stefan Hofer, Henning Schwentner & Avraham Poupko • GOTO 2022

Domain storytelling, iş analizinde, özellikle de yazılım geliştirmede, bir iş sürecini veya işlevselliği anlamak ve iletmek için kullanılır. Çeşitli kullanıcıları, sistemleri ve bunlar arasındaki etkileşimleri görsel bir formatta gösteren hikayeler oluşturulur. Bu, bir iş sürecinin veya sistemler arası etkileşimin anlaşılmasını ve analiz edilmesini kolaylaştırır.

Domain storytelling, genellikle yazılım mühendislerinin ve iş analistlerinin ihtiyaçları daha iyi anlamalarını ve daha etkili çözümler üretmelerini sağlamak için kullanılır. Ayrıca, teknik olmayan kullanıcıların karmaşık iş süreçlerini veya sistemler arası etkileşimleri anlamalarını da kolaylaştırabilir.

Domain storytelling'nin birçok avantajı vardır:

Anlaşılması kolay: Domain storytelling, teknik olmayan kullanıcılara bile karmaşık iş süreçlerini anlatmak için kullanılabilir.

İş süreçlerinin daha iyi anlaşılması: Domain storytelling, bir iş sürecinin veya sistemler arası etkileşimin daha derinlemesine anlaşılmasını sağlar.

Yazılım geliştirme: Domain storytelling, yazılım mühendislerinin iş ihtiyaçlarını daha iyi anlamalarını ve bu ihtiyaçları karşılayan yazılımlar geliştirmelerini sağlar.

Domain storytelling'nin bazı dezavantajları ise şunlar olabilir:

Zaman alıcı: Domain hikayeleri oluşturmak zaman alabilir.

Yorumlama farklılıkları: Farklı insanlar aynı hikayeyi farklı şekillerde yorumlayabilirler.

Teknik kısıtlamalar: Hikayenin oluşturulması ve anlatılması, teknik beceri gerektirebilir.

Domain storytelling, genellikle iş analizinde ve yazılım geliştirmede kullanılır. Ancak, diğer sektörlerde de kullanılabilir. Örneğin, bir finans şirketi, müşterilerine bir hizmetin nasıl çalıştığını anlatmak için domain storytelling kullanabilir. Aynı şekilde, bir sağlık hizmetleri şirketi, hastalarına bir tedavi sürecini anlatmak için domain storytelling kullanabilir.

Domain storytelling'nin uygulanması genellikle aşağıdaki adımları içerir:

Konunun belirlenmesi: Hangi iş sürecinin veya işlevselliğin anlatılacağına karar verilir.

Hikayenin oluşturulması: İş süreci veya işlevsellik hakkında bir hikaye oluşturulur.

Hikayenin görselleştirilmesi: Hikaye, çeşitli kullanıcıları, sistemleri ve bunlar arasındaki etkileşimleri gösteren bir şekil veya diagram ile görselleştirilir.

Hikayenin paylaşılması: Hikaye, ilgili kişilere veya gruplara sunulur.

Domain storytelling, genellikle karmaşık iş süreçlerini veya işlevselliği anlatmak için kullanılan bir tekniktir. Ayrıca, hikayeyi oluşturmak ve paylaşmak için çeşitli teknikler ve araçlar kullanılabilir. Her ne kadar bazı dezavantajları olsa da, domain storytelling'nin birçok avantajı vardır ve birçok işletme tarafından başarıyla kullanılmaktadır.

Domain Storytelling, ayrıca karmaşık iş süreçlerinin veya hizmetlerin kritik yönlerini vurgulamak ve bunları belirginleştirmek için de kullanılabilir. Çünkü çoğu zaman bir şirketin sunmakta olduğu değeri belirleyen şey, sundukları hizmetlerin veya ürünlerin kendileri değil, bunların müşterilere veya kullanıcılara nasıl sunulduğudur. Bu nedenle, bir hizmetin veya ürünün başarısında belirleyici olan adımların ve süreçlerin hikaye şeklinde anlatılması, bu değeri daha net bir şekilde ortaya koyabilir.

Aynı zamanda, domain storytelling, iş süreçlerinin veya sistemlerin iyileştirilmesi için de bir araç olarak kullanılabilir. Hikaye anlatarak, analistler ve mühendisler süreçlerdeki veya sistemlerdeki hataları, eksiklikleri veya verimsizlikleri daha kolay fark edebilir. Bu, süreç veya sistem iyileştirmelerine yol açabilir.

Yine de, unutmamak gerekir ki domain storytelling, bir iş sürecinin veya sistemler arası etkileşimin her yönünü kapsayamayabilir. Özellikle çok büyük ve karmaşık sistemler söz konusu olduğunda, domain storytelling'nin her detayı aktarması zor olabilir. Bu durumda, daha detaylı ve teknik analizlerin yapılması gerekebilir.

Birçok büyük teknoloji şirketi domain storytelling tekniklerini kullanır. Örneğin, Amazon'un ünlü 6-sayfalık memo yaklaşımı, bir tür domain storytelling örneği olabilir. Bu yaklaşımda, bir fikir veya proje hakkında bir hikaye oluşturulur ve bu hikaye, bir projenin veya ürünün her yönünü kapsayan bir "basın bülteni" formatında yazılır. Bu, Amazon'un yeni ürünler veya hizmetler geliştirirken kullanıcılarına ve müşterilerine odaklanmasına yardımcı olur.

Bir başka örnek ise, Spotify'ın Agile modelidir. Bu modelde, ürün geliştirme süreci hikaye anlatma ve görselleştirme teknikleri kullanılarak anlatılır. Bu, takımların ürün geliştirme sürecini daha iyi anlamalarını ve daha etkili bir şekilde katılım sağlamalarını mümkün kılar.

Sonuç olarak, domain storytelling, bir iş sürecini veya işlevselliği anlatmak için güçlü bir araçtır. Hem iş analistlerinin hem de teknik olmayan kullanıcıların karmaşık iş süreçlerini veya sistemler arası etkileşimleri anlamalarını kolaylaştırabilir. Ancak, her hikaye anlatma tekniği gibi, domain storytelling'nin de sınırlamaları vardır ve her durumda kullanılabilir olmayabilir. Bu nedenle, en etkili sonuçları elde etmek için, domain storytelling'nin hangi durumlarda ve nasıl kullanılacağını dikkatlice değerlendirmek önemlidir.

Domain storytelling ayrıca özellikle büyük ölçekli projelerde veya geniş bir işleyiş ve işlevsellik yelpazesi olan organizasyonlarda yararlı olabilir. Her birimin, departmanın veya ekibin görevlerini ve işlevlerini kendi perspektifinden anlaması ve anlatması, tüm organizasyonun daha iyi bir anlayışına ve daha geniş bir bakış açısına sahip olmasını sağlar. Bu, organizasyon içindeki iletişimi ve işbirliğini güçlendirebilir, ve böylece genel verimliliği ve etkinliği artırabilir.

Öte yandan, domain storytelling, yanlış uygulandığında veya hatalı bir şekilde anlatıldığında, yanıltıcı veya karışık olabilir. Örneğin, bir hikayenin çok genel veya çok belirli olması, hikayenin etkinliğini azaltabilir. Ayrıca, hikayenin karmaşık bir konuyu basitleştirmesi gerekirken, bazen çok fazla basitleştirme, konunun gerçek karmaşıklığını ve önemini gizleyebilir. Bu nedenle, domain storytelling'nin etkili olabilmesi için, hikayenin hem anlamlı hem de doğru olması gerekir.

Bunun dışında, domain storytelling, bir organizasyonun içinde veya dışında belirli bir hedef kitleye hitap etmek için stratejik bir araç olarak kullanılabilir. Örneğin, bir organizasyon, domain storytelling kullanarak müşterilere, hissedarlara veya genel halka belirli bir mesaj vermek veya belirli bir imaj oluşturmak isteyebilir. Bu durumda, hikayenin hangi mesajı verdiği ve nasıl anlatıldığı, hedef kitle üzerinde büyük bir etkiye sahip olabilir.

Son olarak, domain storytelling, bazen bir organizasyonun veya ekibin düşüncelerini ve fikirlerini organize etmeye de yardımcı olabilir. Bir hikayenin oluşturulması ve anlatılması süreci, genellikle bir takımın bir konuyu tartışmasını, farklı bakış açılarını değerlendirmesini ve en iyi çözümü belirlemesini gerektirir. Bu süreç, bir takımın daha iyi bir anlayışa ve daha güçlü bir konsensüse ulaşmasına yardımcı olabilir.

Sonuç olarak, domain storytelling, iş süreçlerini, sistemler arası etkileşimleri ve hatta bir organizasyonun değerlerini ve hedeflerini anlatmak için güçlü ve esnek bir araç olabilir. Ancak, bu teknik, etkili olabilmesi için dikkatlice uygulanmalı ve hikayenin hem anlamlı hem de doğru olması gerektiği unutulmamalıdır.

Domain storytelling'de renklendirme ne için kullanılır?

Domain storytelling'de renklendirme, görsel çizimlerin ve diagramların daha etkili iletişim sağlamak için kullanılan bir yöntemdir. İşte renklendirme kullanımının bazı önemli nedenleri:

Görsel Ayrım: Renklendirme, görsel çizimlerde farklı bileşenlerin veya elemanların ayrı ayrı tanımlanmasını sağlar. Örneğin, bir hikaye anlatma çiziminde, kullanıcılar, iş süreçleri, sistem bileşenleri vb. farklı renklerle vurgulanabilir. Bu, okuyucuların çizimdeki farklı unsurları daha kolay ayırt etmelerine yardımcı olur.

İlişkilerin Gösterimi: Renklendirme, çizimlerdeki ilişkileri vurgulamak için kullanılabilir. İlişkili bileşenler veya süreçler aynı renkte gösterilebilir veya belirli bir renk temasıyla vurgulanabilir. Bu, okuyucuların çizimdeki ilişkileri daha hızlı ve daha net bir şekilde anlamalarını sağlar.

Öncelik ve Önem Belirtimi: Renklendirme, çizimdeki bileşenlerin veya süreçlerin öncelik ve önem sırasını belirtmek için kullanılabilir. Önemli veya öncelikli unsurlar belirli bir renkle vurgulanabilirken, daha az önemli olanlar başka bir renkte gösterilebilir. Bu, okuyucuların görsel olarak odaklanması gereken noktaları daha iyi anlamalarını sağlar.

Anlaşılabilirlik ve İletişim: Renklendirme, çizimlerin ve diagramların daha anlaşılır ve etkili bir şekilde iletilmesine yardımcı olur. Farklı renkler, görsel çizimlerdeki karmaşıklığı azaltır ve okuyucuların hızlı ve kolay bir şekilde bilgiyi anlamalarını sağlar. Renklendirme, bilginin daha çekici ve ilgi çekici bir şekilde sunulmasına da katkıda bulunur.

Renklendirme, domain storytelling sürecinde çizimlerin ve diagramların daha etkili bir şekilde iletişim sağlamasına yardımcı olur. Farklı renkler, ayrım yapmayı, ilişkileri göstermeyi, öncelikleri belirtmeyi ve anlaşılabilirliği artırmayı sağlar. Bu da hikayelerin ve görsellerin daha çekici ve anlaşılır olmasını sağlar.

Amazon'un ünlü 6-sayfalık memo yaklaşımı nedir?

Amazon'un 6-sayfalık memo yaklaşımı, şirketin içindeki toplantılar ve karar verme sürecinde kullandığı bir yöntemdir. Bu yaklaşım, şirketin kurucusu Jeff Bezos tarafından uygulanmaya başlanmıştır ve Amazon'un tüm düzeylerindeki çalışanlar tarafından benimsenmiştir.

Bu yöntemde, bir toplantı öncesinde, toplantıya katılacak kişilerden biri, toplantının gündemini belirleyen ve tartışılacak konuları detaylı bir şekilde açıklayan bir memo hazırlar. Bu memo genellikle 6 sayfa uzunluğunda olmalıdır ve genellikle bir basın bülteni formatında yazılır.

Toplantı başladığında, tüm katılımcılar önce memo'yu sessizce okur. Bu sessiz okuma süresi genellikle 30 dakika kadar sürer. Bu, tüm katılımcıların toplantının konusu ve amaçları hakkında tam bir anlayışa sahip olmalarını sağlar. Sessiz okuma süresinin ardından, katılımcılar memo hakkında tartışmaya ve kararlar almaya başlarlar.

Bu yaklaşımın amacı, toplantıların daha odaklı ve verimli hale getirilmesidir. Çünkü, herkesin toplantı öncesi konuyu detaylı bir şekilde anladığından emin olunur. Ayrıca, toplantı sırasında gereksiz veya tekrar eden tartışmaları önlemeye yardımcı olur.

Bu 6-sayfalık memo yaklaşımı, Amazon'un etkili karar verme ve işbirliği yapma kültürünün bir parçasıdır. Aynı zamanda, Amazon'un müşteri odaklı düşünme yaklaşımını da yansıtır, çünkü memo genellikle bir basın bülteni formatında yazılır ve bu da çalışanların müşteri bakış açısını benimsemelerini teşvik eder.

Spotify'ın Agile modeli nedir?

Spotify, Agile prensipleri ve uygulamalarını benimseyen bir teknoloji şirketi olarak bilinir. Agile yaklaşımlar genellikle iş ihtiyaçlarına hızlı ve etkili bir şekilde yanıt verebilmek, işlevselliği hızlı bir şekilde piyasaya sürmek ve sürekli öğrenme ve geliştirme döngülerini teşvik etmek için kullanılır. Spotify, bu yaklaşımları biraz farklı bir şekilde uygulamış ve bu da "Spotify Agile Modeli" olarak bilinir.

Bu model, Spotify'ın iş süreçlerini ve organizasyonel yapısını tanımlar. Spotify'da, ekipler "squads" olarak adlandırılır. Her squad, belirli bir hedefe odaklanır ve bu hedefe ulaşmak için gereken tüm becerilere sahip bir "kendi kendini yöneten" ekiptir. Bu ekipler, kendi kararlarını alabilir ve özerk bir şekilde çalışabilirler.

Squads, daha büyük birimler olan "tribes" içinde gruplanır. Bir tribe, genellikle birkaç squad'ı içerir ve aynı alana odaklanır. Tribes'lerin liderleri genellikle "agile coaches" olarak adlandırılır ve onların görevi, squads'ları desteklemek ve Agile prensiplerini ve uygulamalarını teşvik etmektir.

Spotify Agile Modeli ayrıca "chapters" ve "guilds" adı verilen diğer iki yapıyı daha içerir. Bir chapter, aynı uzmanlık alanına (örneğin, veri bilimi veya kullanıcı deneyimi tasarımı) sahip farklı squads'ların üyelerinden oluşur ve genellikle bir "chapter lead" tarafından yönetilir. Bir guild ise, aynı ilgi alanına sahip farklı tribes ve squads'ların üyelerinden oluşan daha geniş ve daha resmi olmayan bir ağdır.

Bu yapı, Spotify'ın hızlı ve etkili bir şekilde değişen iş ihtiyaçlarına yanıt vermesine ve sürekli öğrenme ve geliştirme döngülerini teşvik etmesine olanak sağlar. Bu yaklaşım ayrıca, ekipler arasındaki iletişimi ve işbirliğini kolaylaştırır ve her ekibin kendi hedeflerine odaklanmasını ve kendi kararlarını almasını sağlar. Ancak, Spotify Agile Modeli'nin her organizasyon için uygun olmayabileceğini ve her organizasyonun kendi ihtiyaçlarına ve koşullarına göre bu modeli uyarlaması gerekebileceğini unutmamak önemlidir.

Amazon'dan ve Spotify'dan çalışma şekilleri olarak domain storytelling'den örnekler verdik. Örnek bir senaryo ile bir yazılım uygulaması için domain storytelling'e örnek verebilir misin?

Elbette. Öncelikle, domain storytelling'nin bir iş sürecini, kullanıcıları ve sistemleri bir hikaye anlatma formatında tanımladığını hatırlayalım. Şimdi, örneğin, bir online sipariş ve teslimat uygulamasını ele alalım.

Hikayemiz şöyle başlayabilir: Sarah, yoğun bir günün ardından eve geldiğinde, akşam yemeği için alışveriş yapmak için süresi olmadığını fark eder. Yorgun olduğu için, hemen telefonunu çıkarır ve online sipariş ve teslimat uygulamasını açar. Sarah, uygulamayı açtığında, ona en son siparişlerini ve en çok sipariş verdiği restoranları hatırlatan önerilerle karşılanır. Sarah, favori restoranlarından birindeki yeni menü seçeneklerine bakar ve bu sefer farklı bir yemek denemeye karar verir.

Sarah, siparişini tamamlar ve ödeme bilgilerini girer. Uygulama, siparişin restorana iletildiğini ve yemeğin ne zaman teslim edileceğini bildirir. Sarah, teslimat sürecini uygulama üzerinden takip eder. Yemek, tahmini teslimat süresi içinde kapısına gelir ve Sarah, yorgun bir günün ardından sıcak bir yemekle rahatlar.

Bu hikaye, online sipariş ve teslimat uygulamasının nasıl çalıştığını ve Sarah gibi bir kullanıcının bu süreçte nasıl etkileşimde bulunduğunu açıkça gösterir. Bu hikaye, uygulamanın kullanıcılarına sunduğu değeri ve onların bu hizmeti nasıl kullandıklarını da vurgular.

Bu hikaye, bir yazılım geliştirme ekibine, uygulamanın kullanıcılarına hangi özellikleri ve işlevleri sunması gerektiğini anlamalarına yardımcı olabilir. Örneğin, hikaye, uygulamanın Sarah'ya önceki siparişlerini ve favori restoranlarını hatırlatan öneriler sunması gerektiğini belirtir. Ayrıca, hikaye, kullanıcının siparişini tamamlama ve teslimat sürecini takip etme yeteneğine sahip olması gerektiğini vurgular.

Sonuç olarak, bu tür bir domain storytelling, bir yazılım geliştirme ekibine, bir uygulamanın hangi özelliklerin ve işlevlerin geliştirilmesi gerektiği konusunda net bir yol haritası sağlar. Bu, ekip üyelerinin uygulamanın neyi başarması gerektiği konusunda ortak bir anlayışa sahip olmasına yardımcı olur ve bu da daha etkili bir yazılım geliştirme süreci sağlar.

Domain storytelling çizimleri nasıl olmaıldır? Çizimlerde hangi elementler kullanılır? Bu elementler arası ilişki nasıl ifade edilir? Çizimlerde sub processler çıkarılabilir mi? Fain grained ve corse grained çizmler nelerdir? To be çizimler nelerdir? 

Domain storytelling, genellikle öyküleri resimlerle ifade etmek için çeşitli çizimler ve simgeler kullanır. Bu çizimler, bir hikayenin karmaşık ayrıntılarını basit ve anlaşılır bir biçimde sunar. Hikaye çizimlerinde genellikle aşağıdaki temel öğeler bulunur:

Aktörler: Aktörler genellikle hikayenin ana karakterleridir. Bir yazılım uygulamasının kontekstinde, bu, belirli işlevlere veya rollerine göre tanımlanan kullanıcılar veya sistemler olabilir.

Olaylar: Olaylar genellikle bir aktörün belirli bir eylemi gerçekleştirdiği veya bir durumu deneyimlediği zamanları temsil eder.

İlişkiler: İlişkiler, aktörler ve olaylar arasındaki bağlantıları ve etkileşimleri gösterir. İlişkiler genellikle oklar veya çizgiler ile temsil edilir ve genellikle bir eylemin yönünü veya akışını gösterir.

Süreçler: Süreçler genellikle bir dizi olayı veya eylemi temsil eder. Bir süreç, genellikle bir başlangıç ve bir bitiş noktası arasındaki olayların bir dizi olarak düşünülebilir. Bir domain hikayesinde, süreçler genellikle bir iş akışı veya iş süreci olarak görülür.

Bir hikaye çiziminde sub-processlerin çıkarılması mümkündür. Bir sub-process, genellikle daha büyük bir sürecin bir parçasını oluşturan daha küçük bir süreçtir. Bir sub-process genellikle daha detaylı veya ince taneli bir bakış açısı sağlar ve genellikle bir sürecin belirli bir bölümünü veya aşamasını gösterir. Bu, bir hikayenin daha karmaşık veya detaylı bir bölümünü daha kolay anlaşılır hale getirebilir.

Coarse-grained ve fine-grained çizimler, hikayenin detay seviyesini temsil eder. Coarse-grained çizimler genellikle bir hikayenin yüksek seviyeli veya genel bir bakışını sunar, daha az detay içerir ve genellikle geniş kavramları veya süreçleri temsil eder. Fine-grained çizimler ise daha fazla detay içerir ve genellikle belirli bir sürecin veya kavramın daha detaylı veya derinlemesine bir anlayışını sunar.

"To be" çizimler, genellikle bir sürecin veya sistemlerin gelecekte nasıl olması gerektiğini gösterir. Bu çizimler, genellikle bir sürecin veya sistemin mevcut durumunu ("as is") temsil eden çizimlere kıyasla, önerilen veya planlanan değişiklikleri veya iyileştirmeleri gösterir.

Bu çizimler, genellikle bir sürecin veya sistemlerin mevcut durumunu anlamak, planlanan değişiklikleri görselleştirmek ve bu değişikliklerin etkisini değerlendirmek için kullanılır. "To be" çizimler, genellikle bir proje veya girişimin başında oluşturulur ve genellikle proje veya girişimin hedeflerini ve sonuçlarını tanımlar.

Domain storytelling de as -is ile to-be storylerin farkı nedir?

Genel olarak, domain storytelling'de "as is" ve "to be" hikayeleri arasındaki farkı açıklamaya çalışabilirim.

Domain storytelling, bir iş alanını (domain) anlamak ve modellemek için kullanılan bir tekniktir. Bu teknikte, gerçek dünya örnekleri ve hikayeleri kullanılır.

"As is" hikayeleri, mevcut durumu, yani iş süreçlerinin, sistemlerin veya uygulamaların şu anki durumunu anlatır. Bu hikayeler, mevcut iş süreçlerini, problemleri ve zorlukları belgelemek için kullanılır.

"To be" hikayeleri ise gelecekteki durumu, yani iş süreçlerinin, sistemlerin veya uygulamaların nasıl olması gerektiğini anlatır. Bu hikayeler, ideal iş süreçlerini, hedefleri ve çözümleri belgelemek için kullanılır.

Bu iki tür hikaye, bir iş alanını anlamak ve iyileştirmek için birlikte kullanılır. "As is" hikayeleri, mevcut durumu anlamak ve problemleri belirlemek için kullanılırken, "to be" hikayeleri, bu problemleri çözmek ve iş süreçlerini iyileştirmek için kullanılır.

Detaylı örnek bir senaryo ile devam eder misin?

Bir e-ticaret şirketini düşünelim. Bu şirketin müşteri hizmetleri departmanı, müşterilerden gelen şikayetleri ve soruları çözmekle görevlidir. Ancak son zamanlarda, müşteri hizmetleri departmanı, müşterilerden gelen talepleri hızlı ve etkili bir şekilde çözme konusunda zorluk çekmeye başlamıştır.

Bu durumu çözmek için, şirket bir domain storytelling oturumu düzenler. Bu oturumda, "as is" ve "to be" hikayeleri oluşturulur.

"As is" hikayesi: Müşteri hizmetleri departmanı, müşterilerden gelen talepleri manuel olarak işlemektedir. Bu süreç, hem zaman alıcı hem de hata yapma olasılığı yüksektir. Ayrıca, departmanın talepleri takip etmek için kullanabileceği bir sistem yoktur. Bu durum, taleplerin kaybolmasına veya yanlış işlenmesine neden olabilir.

"To be" hikayesi: Şirket, müşteri hizmetleri departmanının iş yükünü azaltmak ve hizmet kalitesini artırmak için bir müşteri hizmetleri yönetim sistemi (CRM) kurmayı planlamaktadır. Bu sistem, müşteri taleplerini otomatik olarak işleyecek, takip edecek ve raporlayacaktır. Bu sayede, departmanın işlem süreleri kısalacak ve hata oranı düşecektir.

Bu iki hikaye, şirketin mevcut durumunu anlamasına ve gelecekteki hedeflerini belirlemesine yardımcı olur. Ayrıca, bu hikayeler, şirketin bu hedeflere ulaşmak için hangi adımları atması gerektiğini belirlemesine de yardımcı olur.

Bu hikayeleri oluşturduktan sonra, şirketin bir sonraki adımı bu hedeflere ulaşmak için bir plan oluşturmak olacaktır. Bu plan, "to be" hikayesinde belirlenen hedeflere ulaşmak için gereken adımları içerecektir.

Örneğin, bu plan aşağıdaki adımları içerebilir:

CRM Sistemi Seçimi: Şirket, ihtiyaçlarına en uygun CRM sistemini seçmek için bir araştırma yapar. Bu araştırma, sistemlerin özelliklerini, maliyetlerini ve kullanıcı yorumlarını içerebilir.

Sistem Kurulumu ve Özelleştirme: Seçilen CRM sistemi, şirketin ihtiyaçlarına göre kurulur ve özelleştirilir. Bu aşama, sistem ayarlarının yapılması, gerekli modüllerin eklenmesi ve şirketin iş süreçlerine uygun hale getirilmesi gibi adımları içerir.

Eğitim: Müşteri hizmetleri departmanı, yeni CRM sistemini nasıl kullanacakları konusunda eğitilir. Bu eğitim, sistem özelliklerini, işlevlerini ve en iyi uygulamalarını içerir.

Sistem Testi ve Lansmanı: CRM sistemi, canlıya alınmadan önce kapsamlı bir şekilde test edilir. Bu testler, sistem hatalarını, eksikliklerini ve iyileştirme alanlarını belirlemek için yapılır. Testlerden sonra, sistem canlıya alınır ve müşteri hizmetleri departmanı tarafından kullanılmaya başlanır.

İzleme ve İyileştirme: CRM sisteminin performansı, belirlenen hedeflere ulaşıp ulaşmadığını belirlemek için düzenli olarak izlenir. Gerekli durumlarda, sistemde iyileştirmeler yapılır.

Bu plan, "as is" hikayesinde belirlenen problemleri çözmek ve "to be" hikayesinde belirlenen hedeflere ulaşmak için kullanılır. Bu süreç, domain storytelling'in bir iş alanını anlamak ve iyileştirmek için nasıl kullanıldığının bir örneğidir.

Domain stories with software systems as actors are called DIGITALIZED cümlesinden ne anlamalıyım?

"Domain stories with software systems as actors are called DIGITALIZED" cümlesi, yazılım sistemlerinin aktör olarak yer aldığı hikayelere "digitalized" adı verildiğini ifade eder.

Bu cümle, domain storytelling sürecinde bazen yazılım sistemlerinin de birer aktör olarak gösterilebileceğini ve bu tür hikayelere "digitalized" adı verildiğini belirtmektedir. Yani, bu tür hikayelerde yazılım sistemleri, iş süreçlerinde etkin rol oynayan ve kullanıcı ihtiyaçlarını karşılayan birer aktör olarak tasvir edilir.

Bu ifade, yazılım sistemlerinin iş süreçlerindeki etkisini ve önemini vurgularken, aynı zamanda domain storytelling yönteminin geniş bir uygulama alanına sahip olduğunu gösterir. Yazılım sistemleri, iş süreçlerini otomatize etme, veri işleme veya kullanıcı etkileşimi gibi görevlerde aktif bir rol oynadığından, bu tür hikayelerin dijitalleştirilmiş süreçlerle ilgili olduğu söylenebilir.

Özetle, "Domain stories with software systems as actors are called DIGITALIZED" cümlesi, yazılım sistemlerinin aktör olarak yer aldığı hikayelere "digitalized" adının verildiğini ifade eder ve bu tür hikayelerde yazılım sistemlerinin iş süreçlerindeki etkisini yansıtır.

Domain stroytelling toplantıları nasıl gerçekleştirmelidir?

Domain storytelling toplantılarının düzenlenmesi ve yürütülmesi, hikayeyi oluşturacak ve ondan öğrenmek için birlikte çalışacak bir grup insanın etkili bir şekilde iletişim kurabilmesini gerektirir. Bu tür bir toplantı aşağıdaki adımları içerebilir:

Toplantının Amacını Belirleyin: Toplantının başında, toplantının amacını ve hedeflerini belirlemek önemlidir. Bu, genellikle hangi iş sürecinin veya özelliğin hikayesinin anlatılacağını ve bu hikayenin hangi problemi veya ihtiyacı çözmesi gerektiğini içerir.

Katılımcıları Hazırlayın: Katılımcılar, genellikle hikayenin anlatılacağı süreç veya özellik hakkında bilgi sahibi olan ve bu konuda fikir sahibi olan kişilerdir. Bu, genellikle iş analistleri, kullanıcılar, ürün sahipleri, geliştiriciler ve diğer ilgili tarafları içerir. Bu kişilerin, toplantıya hazırlanmaları ve konu hakkında düşünmeleri için yeterli zamanları olmalıdır.

Stonehenge kurulumu

Hikayeyi Anlatın: Toplantının ana bölümünde, katılımcılar hikayeyi anlatmaya başlarlar. Bu genellikle, süreci veya özelliği tanımlayan bir dizi olayı ve bu olayların birbirine nasıl bağlandığını içerir. Bu aşama genellikle, çeşitli çizimler veya diagramlar kullanılarak gerçekleştirilir.

Hikayeyi Tartışın ve İyileştirin: Hikaye anlatıldıktan sonra, katılımcılar hikayeyi tartışabilir ve iyileştirebilirler. Bu, genellikle hikayenin eksik noktalarını veya belirsizliklerini belirlemeyi ve hikayeyi daha kesin ve anlaşılır hale getirmeyi içerir.

Sonuçları Dokümantasyonla Kaydedin: Toplantının sonunda, hikayenin ve tartışmaların sonuçlarını belgelemek önemlidir. Bu, genellikle hikayenin çizimlerini ve ana noktalarını içerir ve ayrıca tartışılan herhangi bir iyileştirme veya değişikliği de içerir.

Domain storytelling toplantıları genellikle yüz yüze yapılır, ancak çevrimiçi araçlarla da yapılabilir. Önemli olan, katılımcıların hikayeyi anlama ve üzerinde etkili bir şekilde tartışma yeteneğidir. Bu tür bir toplantı, genellikle bir süreci veya özelliği anlamak ve geliştirmek için etkili bir yol olabilir.

Domain stroytelling toplantılarında nelere dikkat edilmelidir? Neler yapılmalı, nelerden kaçınılmalıdır?

Alan (domain) hikâye anlatımı toplantıları, bir ürün, hizmet veya işletme ile ilgili bilgileri çeşitli yönleriyle anlatmak ve ayrıntılı bir bakış açısı sağlamak için gerçekleştirilen oturumlardır. Bu tür toplantılar genellikle UX tasarımcıları, yazılım geliştiricileri, proje yöneticileri ve diğer ilgili paydaşlar arasında düzenlenir. Aşağıda bu tür toplantılarda dikkat edilmesi gereken noktaları bulabilirsiniz:

Katılımcıların Bilgi Seviyesini Anlama: Her katılımcının seviyesini ve konuya ne kadar hakim olduğunu anlamak önemlidir. Bu sayede herkesin konuyu anlaması ve katkıda bulunabilmesi için gerekli bilgi seviyesini ayarlayabilirsiniz.

Hikâyenin Yapısını Belirleme: Alan hikâyesini anlatırken, hikâyenin yapısını belirlemek önemlidir. İyi bir hikâye, genellikle bir giriş, orta kısım ve sonuçtan oluşur. Ayrıca, bir problemi tanımlayabilir, bu probleme nasıl bir çözüm getirileceğini anlatabilir ve çözümün sonuçlarını tartışabilirsiniz.

Bilgileri Basit ve Anlaşılır Tutmak: Hikâyenizi anlatırken, karmaşık terminoloji ve jargonu olabildiğince az kullanmak önemlidir. Anlaşılmaz terimler kullanmak yerine, konuyu herkesin anlayabileceği bir dilde anlatmaya çalışın.

Etkileşimi Teşvik Etmek: Alan hikâye anlatımı toplantıları, genellikle bilgi paylaşımı ve fikir alışverişi için harika fırsatlardır. Katılımcıları soru sormaya, yorum yapmaya ve kendi fikirlerini paylaşmaya teşvik edin.

Geri Bildirim Almak: Toplantının sonunda geri bildirim almak, hikâye anlatımınızın etkili olup olmadığını ölçmenin iyi bir yoludur. Bu, gelecekteki toplantılarınızı iyileştirmenize yardımcı olabilir.

Kaçınılması gereken şeyler:

Tek Taraflı Konuşmalar: Toplantınızın bir monologa dönüşmesine izin vermeyin. Katılımcıları dahil etmek ve onların görüşlerini almak önemlidir.

Fazla Detaya Kaçmak: Tüm detayları paylaşmak yerine, hikâyenin ana hatlarını ve en önemli noktalarını vurgulayın. Ayrıntılara boğulmak, hikâyenin akışını keser ve katılımcıların ilgisini dağıtabilir.

Hedeflerin Belirsiz Kalması: Toplantının sonunda, herkesin hikâyeden ne öğrenmesi gerektiğini ve bundan sonra ne yapılması gerektiğini anlaması gerekir. Hedeflerin belirsiz olması, toplantının verimliliğini düşürebilir.

Gerekli Hazırlıkların Yapılmaması: Hikâye anlatımı, belirli bir planlama ve hazırlık gerektirir. Toplantıya gelmeden önce, anlatacaklarınızı düşünün ve gerektiği kadar not alın. Bu, hikâyenizi daha etkili bir şekilde anlatmanıza yardımcı olur.

Toplantıları kim yönetir? Çizimleri kim yapar? Domain expertler ne iş yapar? Yöneticiler toplantılara davet edilmeli midir?

Toplantıları genellikle proje yöneticileri veya ekip liderleri yönetir. Bu kişiler toplantının amacını belirler, gündemi oluşturur, katılımcıları organize eder ve toplantının ilerleyişini yönetir. Yönetici veya lider, toplantının verimli bir şekilde ilerlemesini sağlamak ve hedeflere ulaşmak için sorumluluk alır.

Çizimler genellikle tasarımcılar veya hikâye anlatımı uzmanları tarafından yapılır. Bu kişiler, konuyu görsel olarak anlatmak ve katılımcıların daha iyi anlamalarını sağlamak için grafikler, diyagramlar veya akış şemaları gibi görsel araçları kullanır. Çizimler, toplantıda paylaşılabilir ve katılımcıların daha iyi bir görsel anlayışa sahip olmalarını sağlar.

Domain expertler (uzmanlar), bir konuda derin bilgiye ve deneyime sahip olan kişilerdir. Toplantılarda, uzmanlar kendi alanlarındaki bilgileri paylaşır, sorulara cevap verir, stratejik yönlendirmelerde bulunur ve proje veya ürün hakkında kritik görüşler sunarlar. Domain expertler, ekip üyelerine ve yöneticilere projenin teknik veya konuyla ilgili yönlerini açıklar ve yardımcı olurlar.

Yöneticiler, proje veya işletme için karar verici pozisyonda olan kişilerdir ve toplantılara davet edilmeleri önemlidir. Yöneticiler, projenin veya ürünün stratejik hedeflerini anlamak ve yönlendirmek için toplantılara katılmalıdır. Ayrıca, yöneticilerin toplantılarda bilgi paylaşması, kararlar alması ve ekibin ilerlemesini izlemesi gerekebilir. Yöneticiler, projenin genel vizyonunu ve hedeflerini temsil ederler ve bu nedenle toplantılarda yer almaları, proje başarısı için önemlidir.

Ama yöneticilerin katılımı ekip üyeleri üzerinde baskı da yaratabilir. Bu konu hakkında ne düşünüyorsun? Bazı durumlarda davet etmemek daha iyi olabilir mi?

Evet, bazı durumlarda yöneticilerin katılımı, ekip üyeleri üzerinde baskı yaratabilir. Ekip üyeleri, yöneticilerin varlığında kendilerini rahatsız veya çekingen hissedebilirler ve bu da açık iletişim ve katılımı olumsuz etkileyebilir. Ayrıca, yöneticilerin bulunduğu toplantılarda, ekip üyeleri kendi fikirlerini veya endişelerini ifade etmekte tereddüt edebilirler.

Bu nedenle, yöneticilerin toplantılara davet edilip edilmemesi konusu dikkatlice değerlendirilmelidir. İşbirliği, katılım ve açık iletişimi teşvik etmek için bazı durumlarda yöneticilerin toplantılardan uzak tutulması tercih edilebilir olabilir. Özellikle yaratıcı fikirlerin ortaya çıktığı veya sorunların çözüldüğü beyin fırtınası veya işbirliği odaklı oturumlar gibi durumlarda, ekip üyelerinin daha rahat hissetmesi ve düşüncelerini özgürce ifade edebilmesi önemlidir.

Ancak, yöneticilerin toplantılara katılımı bazı durumlarda da gereklidir. Özellikle stratejik kararların alındığı, ilerleme raporlarının sunulduğu veya projenin genel hedeflerinin tartışıldığı toplantılarda, yöneticilerin katılımı önemlidir. Yöneticiler, projenin veya işletmenin yönlendirilmesi ve başarıya ulaşması konusunda sorumluluk taşıdıkları için bu tür toplantılarda bilgi sahibi olmalı ve karar alma süreçlerine katılmalıdırlar.

Sonuç olarak, yöneticilerin toplantılara davet edilip edilmemesi durumu, toplantının amacına, konuya ve katılımcıların ihtiyaçlarına bağlı olarak değerlendirilmelidir. İhtiyaçlar ve dinamikler göz önüne alınarak, bazı durumlarda yöneticilerin katılımının azaltılması veya çeşitli toplantı formatlarının kullanılması daha uygun olabilir.

Domain storytelling DDD ilişkisi nedir ve Event Storming'den fark nedir?

Domain storytelling ve Domain-Driven Design (DDD) arasında yakın bir ilişki vardır. DDD, bir yazılım projesinin tasarımını ve uygulamasını, iş domainine odaklanarak gerçekleştiren bir yaklaşımdır. Domain storytelling ise, DDD'nin bir parçası olarak kullanılan bir teknik veya araçtır. Domain storytelling, DDD'nin temel prensiplerini ve fikirlerini iletişim ve paylaşım yoluyla uygulamak için kullanılır.

Domain storytelling, bir iş sürecini, bir sistemi veya bir özelliği anlamak ve tanımlamak için hikaye anlatma tekniklerini kullanır. Bu hikaye, bir yazılım projesinin iş domainini ve kullanıcıları, sistemleri ve etkileşimleri arasındaki ilişkileri açıklamak için kullanılır. Bu da DDD'nin temel fikirlerini ve prensiplerini uygulamak için bir yol sunar.

Öte yandan, Event Storming, bir iş sürecini veya bir yazılım projesini analiz etmek ve anlamak için kullanılan bir atölye çalışması veya işbirliği yöntemidir. Event Storming, bir grup insanın bir araya gelerek, iş domainini ve etkileşimlerini hızlı bir şekilde keşfetmesini ve anlamasını sağlar. Katılımcılar, domaindeki önemli olayları ve bu olaylar arasındaki ilişkileri keşfetmek ve görselleştirmek için post-it notlar ve duvarlar üzerinde çalışır.

Event Storming, DDD'nin bir parçası olarak kullanılan bir yöntemdir ve genellikle DDD projelerinde hikaye anlatmanın bir parçası olarak uygulanır. Event Storming, bir yazılım projesinin hikayesini, iş domainini ve etkileşimleri hızlı ve görsel bir şekilde keşfetmek için kullanılır.

İki yöntem arasındaki fark, odaklandıkları noktalarda yatar. Domain storytelling, bir hikaye anlatma tekniği olarak daha genel bir şekilde kullanılabilirken, Event Storming daha spesifik bir atölye çalışmasıdır ve genellikle bir yazılım projesinin analiz ve keşfi için kullanılır. Domain storytelling, hikaye anlatarak bir iş sürecini veya özelliği anlamak için daha bireysel bir yaklaşım sunarken, Event Storming daha çok bir grup işbirliği ve keşif yöntemidir.

Birlikte kullanıldığında, Domain storytelling ve Event Storming, bir yazılım projesinin iş domainini anlamak, gereksinimleri belirlemek ve etkili bir şekilde iletişim kurmak için güçlü araçlar sağlar.

Domain storytelling user story çıkarmak için kullanılır mı?

Evet, domain storytelling, user story çıkarmak için kullanılan bir yöntem olabilir. Domain storytelling, kullanıcıların ihtiyaçlarını ve iş süreçlerini anlamak için hikaye anlatımını kullanırken, user storyler ise kullanıcıların ihtiyaçlarını ifade etmek için kullanılan kısa açıklamalardır. Domain storytelling sürecinde oluşturulan hikayeler, daha sonra user storyler olarak dönüştürülebilir.

Domain storytelling, kullanıcıların hedefleri, beklentileri ve etkileşimleri hakkında daha derin bir anlayış sağlar. Bu hikayeler, daha sonra user storyler haline getirilerek, geliştirme ekibi tarafından kullanılabilir. User storyler, projenin gereksinimlerini, kullanıcı ihtiyaçlarını ve beklenen sonuçları ifade eder. Bu şekilde, domain storytelling, user storylerin temelini oluşturabilir ve daha iyi bir gereksinim analizi ve planlama sürecine yardımcı olabilir.

Domain storytelling'in user story çıkarma sürecinde kullanılması, kullanıcıların perspektifinden gereksinimleri daha net bir şekilde anlama ve iletişim kurma avantajı sağlar. Ayrıca, hikaye anlatma tekniği, ekip üyeleri arasında işbirliği ve anlayışı artırabilir. Bu, daha iyi bir proje yönetimi ve geliştirme süreci için önemli bir katkı sağlayabilir.

Ancak, domain storytelling'in kullanıcı hikayelerini doğrudan user storylere dönüştürmek için tek başına yeterli olmadığını unutmamak önemlidir. User storyler, daha spesifik ve ölçülebilir olmalıdır. Bu nedenle, domain storytelling sürecinden çıkan hikayeler, gereksinimleri daha iyi ifade etmek için daha fazla detaylandırılmalı ve gerektiğinde user story formatına dönüştürülmelidir.

Domain expertler domain storytelling için ne öneme sahiptir?

Domain expertler, domain storytelling için büyük bir öneme sahiptir. Onlar, belirli bir iş domaininde derinlemesine bilgi ve deneyime sahip olan kişilerdir. Domain expertlerin katılımı, domain storytelling sürecinin başarılı bir şekilde gerçekleştirilmesi için kritik öneme sahiptir ve aşağıdaki nedenlerle önemlidir:

İçgörü ve Doğruluk: Domain expertler, iş domainindeki süreçleri, etkileşimleri ve kullanıcıların ihtiyaçlarını en iyi şekilde anlarlar. Bu bilgi ve deneyimleri, hikaye anlatma sürecinde doğru ve gerçekçi hikayeler oluşturmak için kullanılabilir. Domain expertlerin katkıları, hikayelerin daha içgörülü, doğru ve uygun olmasını sağlar.

Doğru Gereksinimlerin Tanımlanması: Domain expertler, iş domainindeki gereksinimleri belirlemede ve ifade etmede önemli bir rol oynarlar. Onların katkıları, kullanıcıların ihtiyaçlarını daha iyi anlamak, doğru gereksinimleri tanımlamak ve user storylerin oluşturulmasına yardımcı olmak için değerlidir. Domain expertler, gereksinimleri daha spesifik ve ölçülebilir bir şekilde ifade etmede önemli bir rol oynayabilir.

İş Süreçlerinin ve Etkileşimlerin Açıklanması: Domain expertler, iş domainindeki süreçleri, etkileşimleri ve işbirliklerini en iyi şekilde anlayan kişilerdir. Hikaye anlatma sürecinde, domain expertlerin katılımı, bu süreçleri ve etkileşimleri daha iyi açıklamak ve görselleştirmek için önemlidir. Onlar, hikayelerin daha kapsamlı ve anlaşılır olmasını sağlar ve ekip üyeleri arasında bir ortak anlayış oluşturur.

Hata ve Yanlış Anlamaların Azaltılması: Domain expertlerin doğrudan katılımı, hataları ve yanlış anlamaları azaltmaya yardımcı olur. Onlar, yanlış anlaşılan veya eksik bilgileri tespit etmek ve düzeltmek için değerli bir kaynaktır. Bu, gereksinimlerin daha doğru bir şekilde anlaşılmasını ve projenin başarıyla ilerlemesini sağlar.

Domain expertlerin katılımı, domain storytelling sürecinde doğru ve geçerli hikayelerin oluşturulmasını sağlar. Onlar, doğru gereksinimlerin belirlenmesine, iş süreçlerinin açıklanmasına ve yanlış anlamaların azaltılmasına yardımcı olurlar. Bu nedenle, domain expertlerin perspektifi ve bilgisi, domain storytelling sürecinin başarılı bir şekilde gerçekleştirilmesinde önemli bir faktördür.

Domain Stroytelling interview soruları ve cevapları

İşe alım sürecinde Domain Storytelling becerilerini değerlendirmek için aşağıda bazı sorular ve olası cevaplar bulunmaktadır:

Soru: Bir iş sürecini veya sistemi anlamanızı sağlayan bir hikaye anlatın.

Olası Cevap: "Bir online alışveriş sitesi düşünelim. Kullanıcının ürünü seçip sepete eklemesi, ödeme yapması ve teslimatı takip etmesi gibi adımlardan oluşan bir hikaye oluşturabilirim. Kullanıcı, ürün arayışına başlar, seçimini yapar ve sepete ekler. Ardından, ödeme bilgilerini girer ve siparişi tamamlar. Son olarak, teslimat sürecini takip eder ve ürünü alır."

Soru: Bir hizmetin veya ürünün müşteriye nasıl değer kattığını açıklayan bir hikaye anlatın.

Olası Cevap: "Bir müşteri destek yazılımı düşünelim. Bir müşteri, bir sorun veya soruyla karşılaştığında, destek talebini oluşturur ve gönderir. Destek ekibi, talebi alır, sorunu anlar ve çözüm için çalışır. Müşteri, süreci takip eder ve sonunda sorunu çözülür. Bu hikaye, müşterinin sorunlarına çözüm sunarak onlara değer katan bir hizmeti tanımlar."

Soru: Bir sürecin veya sistemin zorluklarını veya eksikliklerini belirten bir hikaye anlatın.

Olası Cevap: "Bir proje yönetim yazılımını ele alalım. Bir proje yöneticisi, projeleri takip etmek, görevleri atamak ve ilerlemeyi izlemek için bu yazılımı kullanır. Ancak, kullanıcı arayüzü karmaşık ve kullanımı zordur. Ayrıca, bazı raporlama ve analitik özellikler eksik olabilir. Bu hikaye, yazılımda karşılaşılan zorlukları ve iyileştirme fırsatlarını açıklayarak sürecin eksikliklerini ortaya koyar."

Soru: Bir süreç veya sistemdeki iyileştirme veya geliştirme önerilerini açıklayan bir hikaye anlatın.

Olası Cevap: "Bir iş sürecini ele alalım. Manuel veri girişi gerektiren bir süreç var. Bu süreç, zaman alıcı ve hatalara neden olabilir. Önerim, otomatik veri entegrasyonu veya bir veri giriş arayüzü eklemek olurdu. Bu şekilde, manuel işlem süresini azaltabilir, veri doğruluğunu artırabilir ve genel verimliliği geliştirebiliriz."

Bu sorular, bir adayın Domain Storytelling becerilerini değerlendirmek için kullanılabilir. Cevaplar, adayın hikaye anlatma yeteneği, iş süreçlerini ve sistemleri anlama yeteneği ve iletişim becerileri hakkında bilgi sağlayabilir. Ancak, gerçek bir mülakatta, adayın tecrübeleri ve kendi örnekleriyle daha ayrıntılı olarak değerlendirilmesi gerekebilir.

Soru: Bir yazılım projesinde domain storytelling'i nasıl kullanırdınız?

Olası Cevap: "Bir yazılım projesinde, domain storytelling'i kullanarak iş süreçlerini ve kullanıcıların ihtiyaçlarını anlamak için hikayeler oluştururdum. Önce, paydaşlarla görüşür ve onların beklentilerini, hedeflerini ve zorluklarını anlamaya çalışırdım. Sonra, bu bilgileri kullanarak, hikaye anlatma tekniklerini kullanarak süreçleri ve etkileşimleri anlatan görsel çizimler oluştururdum. Bu, yazılımın kullanıcıların ihtiyaçlarını nasıl karşılayacağını ve iş süreçlerini nasıl iyileştireceğini daha net bir şekilde göstermeme yardımcı olur."

Soru: Domain storytelling'in bir yazılım projesinde hangi avantajları olduğunu düşünüyorsunuz?

Olası Cevap: "Domain storytelling, bir yazılım projesinde birkaç avantaj sunar. İlk olarak, hikaye anlatma teknikleri, karmaşık süreçleri veya sistemler arası etkileşimleri daha anlaşılır hale getirir ve tüm paydaşların aynı sayfada olmasını sağlar. İkinci olarak, hikayeler, kullanıcıların ihtiyaçlarını ve hedeflerini vurgulayarak kullanıcı odaklı bir yaklaşım sağlar. Ayrıca, hikayeler, fikirleri ve beklentileri paylaşmayı teşvik eder ve ekip üyeleri arasında daha iyi bir işbirliği ve anlayış oluşturur."

Soru: Domain storytelling sürecinde karşılaştığınız zorluklar nelerdir ve bunları nasıl çözersiniz?

Olası Cevap: "Domain storytelling sürecinde bazı zorluklarla karşılaşılabilir. Örneğin, bazı karmaşık iş süreçlerinin veya sistemlerin tüm detaylarını hikaye anlatma formatında sunmak zor olabilir. Bu durumda, daha özetleyici ve odaklanmış bir yaklaşım benimseyerek ana noktaları vurgulamaya çalışırım. Ayrıca, paydaşların farklı beklentileri veya anlayışları olabilir. Bu durumda, açık iletişim ve işbirliği yoluyla ortak bir anlayış oluşturmak için ekstra çaba sarf ederim."

Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Ancak, gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve proje veya senaryolar üzerinde daha fazla ayrıntı paylaşması gerekebilir.

Soru: Domain storytelling'i kullanarak bir iş sürecini veya sistemi anlattığınızda, hangi yöntemleri veya araçları tercih edersiniz?

Olası Cevap: "Domain storytelling sürecinde, görsel çizimler ve diagramlar oluşturmak için genellikle beyaz tahta veya poster kağıtları kullanırım. Bu, hikayenin görsel bir şekilde anlaşılmasını ve katılımcıların daha iyi bir şekilde ilişki kurmasını sağlar. Ayrıca, post-it notlarını ve farklı renklerle yazmayı tercih ederim, böylece farklı bileşenleri ve ilişkileri daha iyi görselleştirebilirim. Buna ek olarak, diğer katılımcıların da hikayeye katkıda bulunmasını sağlamak için açık tartışma ve beyin fırtınası tekniklerini kullanırım."

Soru: Domain storytelling'i kullanarak bir yazılım projesinde paydaşları nasıl etkileşime geçirirdiniz?

Olası Cevap: "Domain storytelling sürecinde, paydaşları etkileşime geçirmek ve katılımlarını sağlamak için düzenli toplantılar ve atölye çalışmaları düzenlerim. Onları hikayenin oluşturulmasına ve geliştirilmesine dahil etmek için aktif olarak sorular sorarım ve fikirlerini paylaşmalarını teşvik ederim. Ayrıca, katılımcılara hikayenin her aşamasında geri bildirim verme fırsatı sunarım ve onların düşüncelerini ve önerilerini dikkate alırım. Bu şekilde, paydaşların sürece dahil olmalarını ve projenin başarısını desteklemelerini sağlarım."

Soru: Domain storytelling'i kullanmanın bir yazılım projesindeki avantajları nelerdir?

Olası Cevap: "Domain storytelling, bir yazılım projesinde birçok avantaj sunar. İlk olarak, tüm paydaşların ortak bir anlayışa sahip olmasını sağlar ve proje gereksinimlerini daha net bir şekilde iletebilir. İkinci olarak, hikayeler, kullanıcı odaklı bir yaklaşımı destekleyerek müşteri ihtiyaçlarını daha iyi anlamayı sağlar. Ayrıca, hikaye anlatma, karmaşık iş süreçlerini veya sistemleri daha anlaşılır ve görsel bir şekilde sunarak iletişimi geliştirir. Bu da daha iyi bir işbirliği ve verimli bir proje geliştirme süreci sağlar."

Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Ancak, gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve proje veya senaryolar üzerinde daha fazla ayrıntı paylaşması gerekebilir.

Soru: Domain storytelling'i kullanarak bir yazılım projesinde işbirliğini nasıl teşvik edersiniz?

Olası Cevap: "Domain storytelling, işbirliği için etkili bir araçtır. Bir yazılım projesinde, paydaşlar arasında işbirliğini teşvik etmek için düzenli paydaş toplantıları ve atölye çalışmaları düzenlerim. Bu toplantılarda, hikaye anlatma tekniğini kullanarak paydaşların görüşlerini ve fikirlerini paylaşmasını teşvik ederim. Ayrıca, farklı perspektiflerden gelen insanları bir araya getirerek daha kapsamlı bir anlayış oluşturmayı hedeflerim. İşbirliğini desteklemek için açık iletişim, aktif dinleme ve geri bildirim alma ve verme süreçlerini kullanırım."

Soru: Domain storytelling sürecinde kullanıcı ihtiyaçlarını nasıl anlarsınız?

Olası Cevap: "Domain storytelling sürecinde, kullanıcı ihtiyaçlarını anlamak için kullanıcıları aktif olarak dahil ederim. Kullanıcıları anlamak için kullanıcı araştırmaları, kullanıcı mülakatları veya kullanıcı testleri gibi kullanıcı merkezli yöntemleri kullanırım. Kullanıcıların günlük rutinlerini, hedeflerini, sorunlarını ve beklentilerini anlamaya çalışırım. Bu bilgileri kullanarak, hikaye anlatma sürecinde kullanıcıların ihtiyaçlarını vurgulayan senaryolar oluşturur ve süreci daha kullanıcı odaklı hale getiririm."

Soru: Domain storytelling'i kullanarak karmaşık bir iş sürecini nasıl basitleştirirsiniz?

Olası Cevap: "Karmaşık bir iş sürecini basitleştirmek için, domain storytelling sürecinde odaklanılacak anahtar noktaları belirlerim. Karmaşık süreci basit bir şekilde anlamak için, sürecin başlangıcını, çıktılarını ve önemli adımlarını belirlerim. Bu adımları ve ilişkileri basitleştirmek için görsel çizimler ve basit simgeler kullanırım. Ayrıca, karmaşık süreci daha anlaşılır hale getirmek için açıklayıcı metinler veya açıklamalar eklerim. Bu şekilde, hikaye anlatma sürecinde karmaşık süreci daha anlaşılır ve erişilebilir bir şekilde sunabilirim."

Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve projeler veya senaryolar üzerinde daha fazla ayrıntı paylaşması beklenir. Ayrıca, mülakatta adayın problem çözme becerileri, iletişim yetenekleri ve işbirliği yetkinlikleri de değerlendirilebilir.

Soru: Domain storytelling'in proje paydaşlarıyla iletişimi nasıl geliştirdiğini açıklayabilir misiniz?

Olası Cevap: "Domain storytelling, proje paydaşlarıyla iletişimi geliştirmek için etkili bir araçtır. Hikaye anlatma sürecinde, paydaşlar projenin iş domainini ve gereksinimlerini daha iyi anlamak için bir araya gelirler. Bu, paydaşların aynı sayfada olmasını ve projenin hedeflerine ortak bir vizyonla yaklaşmalarını sağlar. Hikaye anlatma, görsel çizimler ve senaryolar kullanarak karmaşık kavramları ve etkileşimleri basitleştirir. Bu da paydaşların projenin işleyişini daha iyi anlamalarına yardımcı olur ve gereksinimlerin daha net bir şekilde iletilmesini sağlar. Bu süreç, paydaşlar arasında daha iyi bir iletişim ve işbirliği sağlar."

Soru: Domain storytelling sürecinde kullanılan görsel çizimlerin paydaşlarla nasıl paylaşılacağını açıklayabilir misiniz?

Olası Cevap: "Domain storytelling sürecinde kullanılan görsel çizimler, paydaşlarla paylaşmak için farklı yöntemler kullanılabilir. Öncelikle, çizimleri dijital veya fiziksel ortamlarda paydaşlarla paylaşılabilir. Fiziksel ortamlarda, beyaz tahta, poster kağıdı veya büyük bir kağıt kullanılabilir ve paydaşlarla yüz yüze toplantılarda gösterilebilir. Dijital ortamlarda ise, çizimler sunum veya dokümantasyon aracılığıyla paydaşlarla paylaşılabilir. Ayrıca, paydaşlarla interaktif bir şekilde etkileşime girebilmek için dijital araçlar ve işbirliği platformları da kullanılabilir. Önemli olan, çizimlerin anlaşılır ve erişilebilir bir şekilde sunulması ve paydaşların görüşlerini ve geri bildirimlerini paylaşmaları için ortamın yaratılmasıdır."

Soru: Domain storytelling sürecinde çıkan hikayelerin nasıl dokümante edileceğini açıklayabilir misiniz?

Olası Cevap: "Domain storytelling sürecinde çıkan hikayelerin dokümante edilmesi önemlidir. Bu, hikayelerin gelecekte referans olarak kullanılmasını sağlar. Dokümantasyon için farklı yöntemler kullanılabilir. Örneğin, çizimler ve diagramlar, fotoğraflanabilir veya taranabilir ve bir dokümantasyon sistemine kaydedilebilir. Ayrıca, hikayeler metin formatına dökülebilir ve bir doküman veya sunum dosyası olarak saklanabilir. Bu dokümantasyon, proje sürecinde paydaşlarla ve ekip üyeleriyle paylaşılabilir ve gereksinimlerin, tasarımların ve geliştirmelerin takibi için kullanılabilir."

Bu sorular ve cevaplar, bir adayın Domain Storytelling becerilerini ve deneyimlerini değerlendirmeye yardımcı olabilir. Gerçek bir mülakatta, adayın daha fazla örnek sunması, düşüncelerini derinleştirmesi ve projeler veya senaryolar üzerinde daha fazla ayrıntı paylaşması beklenir. Ayrıca, adayın iletişim becerileri, paydaş yönetimi ve dokümantasyon yetenekleri de değerlendirilebilir.

Domain storytelling de oluşturulan hikayelerden scrum'daki user storyler arasındaki ilişki nedir?

Domain storytelling ve Scrum'daki user storyler arasında bir ilişki vardır. Her ikisi de yazılım geliştirme sürecinde gereksinimleri anlamak ve iletmek için kullanılan yöntemlerdir. İşte bu iki kavram arasındaki ilişkiyi açıklamak için bazı noktalar:

Kullanıcı Odaklılık: Her ikisi de kullanıcıların ihtiyaçlarını anlamak ve bunları geliştirme sürecine yansıtmak için odaklanır. Domain storytelling'de, hikaye anlatma yöntemiyle kullanıcıların hedefleri, beklentileri ve etkileşimleri anlatılır. Scrum'da ise user storyler, kullanıcıların ihtiyaçlarını ifade eden kısa ve net açıklamalardır.

Hikaye Anlatımı: Hem domain storytelling hem de Scrum'daki user storyler, bir hikaye anlatımı biçiminde ifade edilir. Domain storytelling'de, bir hikaye veya senaryo şeklinde iş süreçleri veya sistemler anlatılır. Scrum'da ise user storyler, bir kullanıcı veya paydaşın perspektifinden gereksinimleri ifade eden kısa cümlelerdir.

İletişim ve Paylaşım: Hem domain storytelling hem de Scrum'daki user storyler, ekip üyeleri arasında etkili iletişim ve paylaşımı teşvik eder. Domain storytelling, paydaşlar arasında bir ortak anlayış oluşturmayı hedeflerken, Scrum'da user storyler, ürün sahibi, geliştiriciler ve diğer ekip üyeleri arasında gereksinimleri paylaşmak ve anlamak için kullanılır.

Planlama ve Geliştirme: User storyler, Scrum'daki sprint planlaması ve geliştirme sürecinin temel bir parçasıdır. Scrum ekibi, user storyleri kullanarak sprint hedeflerini belirler ve işi parçalar. Domain storytelling ise, geliştirme öncesinde veya gereksinim analizi aşamasında kullanılır ve projenin genel vizyonunu ve hedeflerini anlamak için bir yol sağlar.

Özet olarak, domain storytelling, kullanıcıların ihtiyaçlarını ve iş süreçlerini anlamak için hikaye anlatımını kullanırken, Scrum'daki user storyler, kullanıcı ihtiyaçlarını ifade eden kısa açıklamalar olarak kullanılır ve sprint planlaması ve geliştirme sürecinin bir parçasıdır. Her ikisi de kullanıcı odaklılığı, hikaye anlatımını ve iletişimi teşvik eder.

Domain storytelling resmi sitesi :

https://domainstorytelling.org/

Araçlar :

Egon.io : Domain storytelling'ler oluşturmak için basit bir araç.

Kitaplar : 

Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software : https://learning.oreilly.com/library/view/domain-storytelling-a/9780137458974/