Event Storming, yazılım geliştirme ve iş süreçlerinin tasarlanması için kullanılan bir teknik olup, özellikle Domain-Driven Design (DDD) yaklaşımında popülerdir. Temel amacı, bir sistemdeki tüm olayları (events) bir araya getirerek sistemin nasıl çalıştığını anlamak ve iş süreçlerini görselleştirmektir. Genellikle etkileşimli bir atölye çalışması şeklinde uygulanır.
Event Storming’in Ana Özellikleri:
1. Olay Odaklılık (Event-Centric): Sürecin merkezinde sistemde meydana gelen olaylar vardır. Bir olay (event), sistemin işleyişinde anlamlı bir değişikliği ifade eder (örneğin, "Sipariş Verildi" ya da "Ödeme Alındı").
2. Katılımcı Yaklaşım: Yazılım geliştiriciler, iş analistleri, domain uzmanları, ürün sahipleri ve diğer paydaşlar bir araya gelerek sistemi anlamaya ve modellemeye çalışır. Bu, ekipteki herkesin katkı sağlayabileceği bir yöntemdir.
3. Görsel Araçlar Kullanımı: Post-it, yapışkan notlar, beyaz tahta gibi görsel araçlar kullanılarak olaylar, komutlar (commands), aktörler ve diğer bileşenler görselleştirilir. Her olay bir yapışkan nota yazılır ve zaman sıralamasıyla tahtaya yerleştirilir.
4. Zaman Sıralaması: Olaylar genellikle zaman sıralı olarak yerleştirilir, bu sayede sistemin nasıl işlediği adım adım takip edilebilir.
5. Büyük Resim: Event Storming sayesinde sistemin genel yapısı ve iş süreçleri üzerinde geniş bir perspektif elde edilir. Karmaşık sistemlerdeki boşluklar, yanlış anlamalar ve eksiklikler hızlıca fark edilebilir.
Event Storming Adımları:
1. Olayları Belirleme: Sistemde meydana gelen tüm iş olayları tespit edilir ve sıraya dizilir.
2. Komutlar ve Aktörler: Olayları tetikleyen komutlar ve bu komutları gerçekleştiren aktörler belirlenir.
3. Toplu Görselleştirme: Tüm bu bileşenler görselleştirilerek sistemin bütüncül bir haritası çıkarılır.
4. Detaylandırma ve Boşlukları Doldurma: Elde edilen olaylar üzerinden süreç detaylandırılır ve eksik ya da belirsiz noktalar açığa çıkarılır.
Event Storming’in Faydaları:
• Hızlı bir öğrenme ortamı sağlar: Sistemin tüm paydaşları arasında hızlı bir bilgi paylaşımı yapılır.
• Karmaşıklığı azaltır: Sistemin karmaşık kısımları görsel olarak basitleştirilir.
• Keşif sürecini hızlandırır: İş süreçlerindeki eksiklikler ve sorunlar daha hızlı fark edilir.
• Takım iş birliğini artırır: Yazılım geliştirme ekibi ile domain uzmanları arasında daha etkili bir iş birliği sağlar.
Event Storming, özellikle büyük ve karmaşık sistemlerde, iş süreçlerini anlamak ve modellemek için etkili bir yöntemdir. Bu teknik, bir yazılım sisteminin doğru şekilde modellenmesine yardımcı olur ve Domain-Driven Design (DDD) prensiplerine uygun bir çözüm geliştirilmesini sağlar.
Bileşenleri nelerdir?
Event Storming’in bileşenleri, sistemin işleyişini anlamak ve modellemek için kullanılan çeşitli unsurları içerir. Bu bileşenler, sistemdeki olayları, aktörleri, komutları ve daha fazlasını temsil eder. İşte Event Storming’in temel bileşenleri:
1. Olaylar (Events)
• Tanım: Sistemde meydana gelen önemli bir durumu veya değişikliği temsil eder. Genellikle "şu olay gerçekleşti" şeklinde ifade edilir.
• Örnekler:
o “Sipariş Verildi”
o “Ödeme Alındı”
o “Kullanıcı Kaydı Tamamlandı”
• Temsil: Genellikle post-it veya yapışkan notlarda yazılarak zaman sırasına göre duvara yerleştirilir. Olaylar, sistemin temel adımlarını anlamak için kullanılır.
2. Komutlar (Commands)
• Tanım: Bir olayın gerçekleşmesine neden olan bir aksiyonu ifade eder. Komutlar, genellikle bir aktör tarafından başlatılan ve sistemin bir işlem yapmasını tetikleyen emirlerdir.
• Örnekler:
o “Sipariş Ver”
o “Ödeme Yap”
o “Ürünü Sepete Ekle”
• Temsil: Komutlar, olaylardan önce gelen aksiyonlar olarak genellikle farklı renkte notlarla temsil edilir.
3. Aktörler (Actors)
• Tanım: Komutları tetikleyen kişi, sistem ya da dış bir varlıktır. Aktör, bir olayın gerçekleşmesine neden olan komutu başlatan tarafı temsil eder.
• Örnekler:
o “Kullanıcı”
o “Müşteri”
o “Ödeme Sistemi”
• Temsil: Aktörler genellikle olayların öncesinde yer alan komutları başlatan kişi veya sistem olarak işaretlenir.
4. Toplamalar (Aggregates)
• Tanım: Sistemdeki önemli veri kümelerini veya durumu temsil eden iş mantığıyla dolu nesnelerdir. Olaylar ve komutlar bu veri yapıları üzerinde çalışır.
• Örnekler:
o “Sipariş Nesnesi”
o “Ürün Stoğu”
• Temsil: Toplamalar genellikle bir olayın veya komutun etkilendiği alanları gösteren gruplamalar olarak kullanılır.
5. Sınırlar (Bounded Contexts)
• Tanım: Farklı iş birimlerinin ya da alt sistemlerin sınırlarını ifade eder. Her bir "Bounded Context", kendi iş mantığına ve veri modeline sahip olabilir.
• Örnekler:
o “Sipariş Yönetimi”
o “Ödeme İşlemleri”
o “Stok Yönetimi”
• Temsil: Genellikle çizgiler veya farklı alanlarla sınırlar belirlenir. Farklı bounded context'ler sistemin farklı bölümlerini anlamamıza yardımcı olur.
6. Oklar ve Akış (Flows)
• Tanım: Olaylar arasında zaman sıralamasıyla gerçekleşen işlemler arası ilişkiyi ifade eder. Sistem akışını ve bileşenler arasındaki etkileşimi görselleştirir.
• Temsil: Olaylar ve komutlar arasında bağlantı kurmak için oklar kullanılır. Bu akış, olayların nasıl birbiriyle ilişkili olduğunu gösterir.
7. Politikalar (Policies)
• Tanım: Sistem içerisindeki iş kurallarını veya tetikleyici koşulları temsil eder. Politikalar, olaylar gerçekleştiğinde ne yapılacağını belirler.
• Örnekler:
o “Eğer stok tükenmişse, siparişi iptal et”
o “Ödeme onaylandıysa, siparişi işleme al”
• Temsil: Genellikle farklı bir renkte ya da işaretle belirlenen kurallardır.
8. Soru İşaretleri ve Problemler
• Tanım: Sistemde anlaşılmayan ya da belirsiz olan konuları temsil eder. Süreçte eksik veya çözülmemiş sorunlar olabilir.
• Temsil: Soru işaretleri ya da belirsizlikler genellikle bir post-it üzerine “?” işaretiyle yazılır ve çözülmesi gereken alanlar olarak işaretlenir.
9. Zamanlayıcılar (Schedulers/Timers)
• Tanım: Belirli bir süre sonra veya düzenli olarak tetiklenmesi gereken işlemleri temsil eder. Örneğin, belirli bir sürede tamamlanmayan işlemlerin iptal edilmesi gibi durumlar zamanlayıcılarla ifade edilir.
• Temsil: Bir zamanlayıcı tetiklenmesi gereken belirli olaylarla ilişkilendirilir.
10. Dış Sistemler (External Systems)
• Tanım: Sistemin dışındaki üçüncü taraf servisler ya da diğer sistemlerle etkileşimi ifade eder. Örneğin, bir ödeme sağlayıcısı veya dış bir veri kaynağı bu kategoriye girer.
• Örnekler:
o “Ödeme sağlayıcısı”
o “E-posta gönderim sistemi”
• Temsil: Sistemin sınırlarının dışında yer alır ve genellikle farklı bir renkle işaretlenir.
11. Okuma Modelleri (Read Models)
• Tanım: Verilerin sistemde nasıl gösterildiğini veya sorgulandığını ifade eder. Event Storming’de, genellikle olaylar sonrası bilginin nasıl elde edileceğini gösterir.
• Örnekler:
o “Sipariş Durumu Raporu”
o “Ürün Stok Listesi”
• Temsil: Olaylar sonrası oluşan durumu ifade eden notlar veya çizimler şeklinde gösterilir.
12. Komutları İşleyen Sistemler (Command Handlers)
• Tanım: Komutları işleyip olayları tetikleyen kod parçalarını veya sistemi temsil eder. Bir komut işlendiğinde belirli olaylar yaratılır.
• Temsil: Komutların nasıl işlendiğini göstermek için kullanılan bir bileşendir.
Event Storming’de bu bileşenler bir araya gelerek sistemin işleyişini adım adım çözümlememizi sağlar. Özellikle karmaşık iş süreçlerinde bu bileşenlerin etkileşimi, sistemin genel işleyişini ve potansiyel sorunları daha kolay görmemize yardımcı olur.
4o
Event stormingde Bounded contextler ve microserviceler nasıl bulunur?
ChatGPT
Event Storming, karmaşık iş süreçlerini ve sistemleri modellemek için kullanılan bir teknik olduğundan, bu süreç içerisinde Bounded Context'ler (sınırlandırılmış bağlamlar) ve microservice'ler gibi yapılar sistemin doğal bir sonucu olarak ortaya çıkabilir. Bounded Context ve microservice'leri bulmak, genellikle sistemdeki olaylar ve iş süreçlerinin etkileşimine dayalı bir ayrıştırma süreciyle gerçekleşir. İşte Event Storming sürecinde bu yapıları nasıl bulabileceğinizle ilgili adımlar:
1. Olayları Belirleyin
İlk adımda, sistemde gerçekleşen önemli olayları belirleyin. Olaylar, sistemdeki iş süreçlerinin en temel birimleridir. Örneğin:
• "Sipariş Verildi"
• "Ödeme Alındı"
• "Sipariş Gönderildi"
Bu olayları sırayla dizip aralarındaki ilişkileri anlamaya başladığınızda, sistemin nasıl çalıştığı hakkında genel bir fikir edineceksiniz.
2. Olayların Gruplarını ve Doğal Ayrışmayı Fark Edin
Olayları yerleştirirken doğal olarak bazı olayların birbirine daha fazla bağlı olduğunu fark edebilirsiniz. Bu bağlı olay grupları, iş süreçlerinin farklı bölümlerini ya da iş birimlerini temsil eder. Örneğin, “Ödeme Alındı” olayı, ödeme yönetimi bağlamında yer alırken, “Sipariş Gönderildi” olayı lojistikle ilgili bir bağlamda bulunabilir.
İşte bu gruplar Bounded Context'lerin işaretleridir. Her Bounded Context, iş süreçlerinin ve veri modellerinin belirli bir alt kümesini içerir ve diğerlerinden ayrıdır.
3. İş Kurallarını ve Politikaları İnceleyin
Farklı olaylar için geçerli olan iş kuralları (policies) ve politikalar da Bounded Context'leri belirlemede yardımcı olabilir. Örneğin, bir ödeme işlemi sırasında geçerli olan iş kuralları ile bir siparişin gönderilmesiyle ilgili kurallar birbirinden farklı olabilir. Bu farklılıklar, iş süreçlerinin kendi sınırları içinde kalması gerektiğini gösterir ve her iş süreci bir Bounded Context olarak ayrıştırılabilir.
4. Aktörlerin ve Komutların Etkileşimini Değerlendirin
Sistemde yer alan farklı aktörlerin (actors) ve komutların (commands) olaylar üzerindeki etkisi, Bounded Context ve microservice'lerin ayrışmasına yardımcı olur. Örneğin:
• Bir müşteri, "Sipariş Ver" komutunu gönderir ve bu sipariş süreci ile ilgili olaylar tetiklenir.
• Bir başka aktör (örneğin, lojistik departmanı), "Siparişi Gönder" komutunu tetikler.
Bu tür farklı aktörler ve komutlar, iş süreçlerinde ayrışmanın işaretleridir. Bu komutlar ve aktörler, farklı microservice'lerin sorumluluk alanlarına işaret edebilir.
5. Sınırları Çizme: Bounded Context'leri Belirleme
Event Storming sırasında, olaylar ve iş süreçleri arasında doğal bir sınır belirginleşmeye başlar. Bu noktada Bounded Context'leri belirlemek için şu kriterlere bakabilirsiniz:
• Farklı Veri Modelleri: Her bir bağlam, kendi veri modeline sahip olmalıdır. Örneğin, “Sipariş Yönetimi” bağlamında sipariş bilgileri yer alırken, “Ödeme Yönetimi” bağlamında ödeme bilgileri yer alır.
• İş Kurallarının Farklılığı: Bağlamlar arasında iş kuralları (business rules) net bir şekilde farklılaşmalıdır.
• Dil ve Terimler: Farklı Bounded Context'ler, kendi terimlerine ve diline (Ubiquitous Language) sahiptir. Bu dil, belirli bir iş süreci etrafında şekillenir.
6. Microservice'leri Tanımlama
Bounded Context'leri belirledikten sonra, bunları genellikle birer microservice olarak tasarlamak mantıklıdır. Her Bounded Context, belirli bir iş sürecini ya da işlevi kapsar ve izole bir şekilde çalışmalıdır. Microservice'lerin belirlenmesi için aşağıdaki faktörler göz önünde bulundurulabilir:
• Tek Sorumluluk İlkesi (Single Responsibility Principle): Her microservice, tek bir iş süreci ya da işlevle ilgilenmelidir. Örneğin, "Ödeme Yönetimi" ve "Sipariş Yönetimi" iki ayrı microservice olarak tasarlanabilir.
• Olay Tabanlı İletişim: Microservice'ler genellikle birbirleriyle olaylar (events) aracılığıyla iletişim kurar. Event Storming’de belirlediğiniz olaylar, microservice'lerin birbirlerine nasıl mesaj göndereceğini gösterebilir.
• Bağımsız Dağıtım (Independent Deployment): Her Bounded Context, bağımsız olarak geliştirilip dağıtılabilecek şekilde ayrılmalıdır. Bu, her bir microservice'in kendi başına dağıtılabilir ve yönetilebilir olması gerektiği anlamına gelir.
7. Olaylar Arası Bağımlılıkları Değerlendirme
Microservice'ler arası iletişim ve bağımlılıklar da bu süreçte netleşir. Farklı Bounded Context'lerin ya da microservice'lerin birbirlerine nasıl bağımlı olduklarını belirlemek için olaylar arası ilişkileri inceleyin. Örneğin, bir microservice'in ürettiği olayın (örneğin, “Ödeme Alındı”) başka bir microservice tarafından tüketilmesi gerekebilir (“Siparişi Gönder”).
8. Zorluklar ve Boşlukları Keşfetme
Bounded Context'leri ve microservice'leri belirlerken, süreçteki boşluklar ve zorluklar da açığa çıkabilir. Bu noktada, sistemde eksik kalan yerleri doldurmak ve sınırların nerede olması gerektiğini netleştirmek için Event Storming çalışmanızı tekrar gözden geçirin.
Özetle:
• Bounded Context'ler, iş süreçleri ve olaylar arasında doğal sınırların belirginleştiği yerlerde ortaya çıkar. Her Bounded Context, bir iş sürecini kapsar ve kendi veri modeline, iş kurallarına sahip olur.
• Microservice'ler ise bu Bounded Context'ler üzerine inşa edilir. Her microservice, tek bir bağlamdan sorumlu olmalı, izole çalışabilmeli ve birbirleriyle olaylar aracılığıyla haberleşmelidir.
Event Storming, bu ayrıştırma sürecinde ekiplerin iş birliği yaparak sistemdeki sınırları, bağımlılıkları ve iş süreçlerini net bir şekilde anlamalarına yardımcı olur.
Etkinliğe kimler katılmalı?
Event Storming’e katılacak kişiler, projenin ya da sistemin tüm yönlerini anlamak ve modellemek için çeşitli yetkinliklere sahip olmalıdır. Bu etkinlik, sadece yazılım geliştiricilerle sınırlı değildir; sürece işin uzmanları ve paydaşları da dahil olmalıdır. Farklı bakış açıları ve uzmanlıkların bir araya gelmesi, sistemin bütüncül bir şekilde anlaşılmasını sağlar.
Event Storming’e Katılması Gereken Kişiler
1. Domain Uzmanları (Subject Matter Experts – SMEs)
o Kimdir? İş sürecini en iyi bilen, işin işleyişi hakkında derin bilgiye sahip olan kişilerdir. Bu kişiler, iş alanında yıllardır deneyimi olan bireyler olabilir.
o Neden Katılmalı? Domain uzmanları, iş süreçlerinin nasıl çalıştığını ve hangi olayların önemli olduğunu en iyi şekilde anlayabilirler. Süreçlerin doğruluğunu sağlamak için kritik bir role sahiptirler.
o Rolü: Sistemin hangi olayları içerdiğini belirlemek, iş kurallarını açıklamak, iş süreçlerindeki kritik noktaları tanımlamak.
2. Yazılım Geliştiriciler (Developers)
o Kimdir? Sistemi geliştirecek olan teknik ekip üyeleridir. Genellikle yazılım mühendisleri, backend ve frontend geliştiriciler bu rolü üstlenir.
o Neden Katılmalı? Yazılım geliştiriciler, iş süreçlerinin teknik olarak nasıl uygulanacağını ve sistemin hangi kısımlarında ne gibi zorluklarla karşılaşılabileceğini değerlendirirler.
o Rolü: Domain uzmanlarının verdiği iş bilgilerini teknik tasarıma dönüştürmek, event tabanlı sistemin nasıl uygulanacağını anlamak, microservice’lerin sınırlarını belirlemek.
3. Ürün Sahipleri (Product Owners)
o Kimdir? Ürün sahibi, sistemin son kullanıcıya sağladığı değeri en iyi bilen kişidir. Ürün stratejisi, kullanıcı ihtiyaçları ve ürün geliştirme süreçlerinden sorumludur.
o Neden Katılmalı? Ürün sahipleri, kullanıcı ihtiyaçlarını en iyi şekilde temsil eder ve olayların kullanıcı deneyimi açısından ne kadar değerli olduğunu değerlendirebilirler.
o Rolü: Sistemin işleyişini kullanıcının bakış açısıyla değerlendirmek, iş süreçlerindeki kullanıcı odaklı olayları ön plana çıkarmak, iş önceliklerini belirlemek.
4. İş Analistleri (Business Analysts)
o Kimdir? İş süreçlerini analiz eden ve iş gereksinimlerini yazılım çözümlerine dönüştüren kişiler.
o Neden Katılmalı? İş analistleri, iş süreçlerinin doğru bir şekilde modele dökülmesine yardımcı olurlar. Domain uzmanları ile geliştiriciler arasında bir köprü görevi görürler.
o Rolü: İş gereksinimlerini netleştirmek, olayların iş süreçleri üzerindeki etkisini anlamak ve analiz etmek, eksik ya da belirsiz noktaları tespit etmek.
5. Test Uzmanları (QA/Testers)
o Kimdir? Sistemi test eden ve kalite güvencesinden sorumlu olan kişiler.
o Neden Katılmalı? Test uzmanları, olayların doğru bir şekilde gerçekleşip gerçekleşmediğini ve iş süreçlerinin bütünlüğünü denetlemek için süreçlerin nasıl test edileceğini belirlerler.
o Rolü: Olayların nasıl test edileceğini anlamak, sistemdeki her olayın bir test senaryosuna nasıl dönüştürüleceğini planlamak.
6. Mimarlar (Architects)
o Kimdir? Sistemin genel yapısını tasarlayan teknik uzmanlardır. Özellikle büyük projelerde, yazılım mimarları teknik yönlendirme sağlarlar.
o Neden Katılmalı? Mimarlar, sistemin genel yapısını tasarlarken olaylar ve mikroservisler arasındaki bağımlılıkları, veri akışını ve teknik kararları alırlar.
o Rolü: Microservice sınırlarını belirlemek, sistemin genel mimarisini tasarlamak, teknik zorlukları ve çözümleri önermek.
7. Proje Yöneticileri (Project Managers)
o Kimdir? Projeyi yönetmek ve ilerleyişi izlemekle sorumlu olan kişilerdir.
o Neden Katılmalı? Proje yöneticileri, projenin kapsamını, zamanını ve bütçesini yönetmekle sorumlu oldukları için sürecin gerçekçi ve yönetilebilir olmasını sağlarlar.
o Rolü: Sürecin iş hedeflerine uygun ilerlediğinden emin olmak, olayların ve iş süreçlerinin proje planlarına nasıl entegre edileceğini değerlendirmek.
Katılımcıların Rol Dağılımı
• Domain uzmanları ve ürün sahipleri, iş süreçlerini ve olayları açıklığa kavuşturur.
• Geliştiriciler ve mimarlar, bu olayları teknik bir bakış açısıyla yorumlar ve olayların nasıl uygulanacağını belirler.
• İş analistleri, bu iki grubun (teknik ve iş tarafının) uyum içinde çalışmasını sağlar.
• Test uzmanları, sistemin işleyişinin doğrulanabilir olduğunu garanti altına alır.
• Proje yöneticileri, etkinliğin iş hedeflerine uygun şekilde ilerlemesini sağlar.
Neden Bu Kişiler Katılmalı?
Event Storming’in gücü, tüm paydaşların birlikte çalışarak sistemi anlamasından gelir. Farklı uzmanlık alanlarına sahip kişilerin bir araya gelmesi, olası yanlış anlaşılmaları önler, sistemin boşluklarını ortaya çıkarır ve tüm tarafların süreçle ilgili görüşlerini paylaşmasını sağlar. Bu, hem iş süreçlerinin daha net bir şekilde modellenmesine hem de yazılım geliştirme sürecinde daha az hata yapılmasına katkıda bulunur.
Özetle:
Event Storming’e, iş süreçleri ve yazılım geliştirme açısından sistemi etkileyen tüm kilit paydaşların katılması önerilir. Bu, iş süreçlerinin en iyi şekilde modellenmesine ve yazılımın doğru bir şekilde geliştirilmesine olanak tanır.
Kullanabileceğim online araçlar var mı?
-
ChatGPT
Evet, Event Storming atölyelerini çevrimiçi olarak düzenlemek için çeşitli araçlar kullanabilirsiniz. Özellikle uzaktan çalışan ekipler için bu tür araçlar, iş birliğini ve sürecin etkinliğini artırmada çok faydalı olabilir. Aşağıda Event Storming için kullanabileceğiniz popüler online araçları bulabilirsiniz:
1. Miro
• Ne İşe Yarar? Miro, dijital beyaz tahta uygulamaları arasında en popüler olanlardan biridir. Event Storming atölyeleri için geniş bir çalışma alanı sunar ve yapışkan notlar, oklar, gruplama araçları gibi görsel bileşenlerle olayları, komutları ve aktörleri modellemenize olanak tanır.
• Özellikler:
o Kullanıcı dostu arayüz.
o Takım üyeleriyle gerçek zamanlı iş birliği.
o Yapışkan notlar, şemalar ve çizim araçları.
o Zaman sınırı olmaksızın büyük beyaz tahtalar oluşturma.
• Web Sitesi: Miro
2. MURAL
• Ne İşe Yarar? MURAL, çevrimiçi iş birliği ve beyin fırtınası yapmak için kullanılan güçlü bir dijital beyaz tahta aracıdır. Event Storming etkinliklerinde ekiplerin bir araya gelerek olayları organize etmelerine ve sistemin genel işleyişini modellemelerine yardımcı olur.
• Özellikler:
o Kolayca post-it benzeri notlar ekleyip olayları sıralama.
o Farklı renkler ve şekillerle olayları, komutları, ve aktörleri görselleştirme.
o Gerçek zamanlı katılım ve yorum yapma.
• Web Sitesi: MURAL
3. Lucidchart
• Ne İşe Yarar? Lucidchart, şemalar ve diyagramlar oluşturmak için popüler bir araçtır. Event Storming atölyeleri için, sistemdeki olayların görsel olarak modellenmesine olanak tanır. Özellikle teknik diyagramlar ve şemalar için etkili bir araçtır.
• Özellikler:
o Zengin diyagram ve şema araçları.
o Post-it ve şekil ekleme seçenekleri.
o Google Drive ve diğer araçlarla entegrasyon.
• Web Sitesi: Lucidchart
4. Jamboard
• Ne İşe Yarar? Google’ın ücretsiz dijital beyaz tahta uygulaması olan Jamboard, özellikle küçük ekipler için basit bir iş birliği aracı olarak kullanılabilir. Event Storming için olayları organize etmenize ve ekiplerle anında paylaşmanıza olanak tanır.
• Özellikler:
o Basit ve kullanımı kolay bir arayüz.
o Google ekosistemine entegre çalışma (Drive, Meet, vb.).
o Gerçek zamanlı iş birliği.
• Web Sitesi: Jamboard
5. Stormboard
• Ne İşe Yarar? Stormboard, çevrimiçi bir beyin fırtınası ve iş birliği aracıdır. Post-it benzeri yapışkan notlarla etkinliklerinizi modellemenize olanak tanır ve Event Storming için kullanılabilir. Olaylar, komutlar ve aktörler gibi bileşenleri hızlıca organize etmenize yardımcı olur.
• Özellikler:
o Yapışkan notlar, çizim araçları ve iş birliği özellikleri.
o Takım üyeleriyle eş zamanlı çalışma imkanı.
o Notlar ve etkinlikler için şablonlar sunar.
• Web Sitesi: Stormboard
6. FigJam (Figma)
• Ne İşe Yarar? Figma’nın dijital beyaz tahta aracı olan FigJam, iş birliği ve beyin fırtınası için güçlü bir platformdur. Event Storming için olayları ve iş süreçlerini görselleştirmenizi sağlar.
• Özellikler:
o Post-it notlar, oklar, şemalar ve işaretlemeler ekleme.
o Gerçek zamanlı iş birliği.
o Figma ile entegrasyon (tasarımcılar için faydalı olabilir).
• Web Sitesi: FigJam
7. Whimsical
• Ne İşe Yarar? Whimsical, iş birliği ve beyin fırtınası yapmak için görsel bir araçtır. Event Storming atölyeleri için yapışkan notlar, zaman çizelgeleri ve diyagramlar oluşturmanıza olanak tanır.
• Özellikler:
o Kolay kullanımlı ve minimalist bir arayüz.
o Zengin iş birliği seçenekleri.
o Farklı renklerle notlar ekleyip olayları organize etme.
• Web Sitesi: Whimsical
8. Excalidraw
• Ne İşe Yarar? Excalidraw, basit bir dijital çizim ve şema aracıdır. Event Storming etkinlikleri için hızlıca olaylar ve iş süreçlerini çizebilir, ekiplerle anında paylaşabilirsiniz.
• Özellikler:
o Çok basit ve kullanımı hızlı bir arayüz.
o Gerçek zamanlı iş birliği.
o Çizim odaklı olmasıyla hızlıca olayları görselleştirme.
• Web Sitesi: Excalidraw
9. Parabol
• Ne İşe Yarar? Parabol, çevrimiçi retrospektif ve beyin fırtınası aracı olarak kullanılan bir platformdur. Event Storming çalışmaları için de uyarlanabilir. Süreçleri ve olayları adım adım görselleştirmeye imkan tanır.
• Özellikler:
o İş süreçlerini organize etmek için uygun şablonlar.
o Kolay kullanımlı arayüz ve eş zamanlı iş birliği.
• Web Sitesi: Parabol
10. Lean Coffee Table
• Ne İşe Yarar? Lean Coffee Table, beyin fırtınası ve tartışma yönetimi için kullanılan bir araçtır. Event Storming sürecinde farklı fikirleri ve olayları kolayca organize etmek için faydalı olabilir.
• Özellikler:
o Post-it notlar ve iş süreçlerini organize etmek için şablonlar.
o Zaman yönetimi ve süreç takibi.
• Web Sitesi: Lean Coffee Table
Özetle:
• Miro ve MURAL, en popüler ve kapsamlı araçlar arasında yer alır ve Event Storming için ideal bir ortam sunar.
• Lucidchart ve Whimsical, daha diyagram ve şema odaklı yaklaşımlar arayanlar için uygundur.
• Jamboard ve Stormboard, daha basit ve kolay kullanımlı araçlar arayan ekipler için idealdir.
Bu araçlar sayesinde, Event Storming etkinliğini çevrimiçi ortamda düzenleyebilir ve ekip üyelerinizle etkin bir şekilde iş birliği yapabilirsiniz.