زمانی که صحبت از توسعه نرم افزار به میان می‌آید، اولین مسئله‌ای که به ذهن مدیر پروژه یا توسعه دهنده‌ها خطور می‌کند، تحلیل آن سیستم و همچنین تحلیل کسب و کار است. رایج‌ترین روش برای این کار، صحبت کردن با کسانی است که به عنوان متخصص کسب و کار (Business Expert) می‌شناسیم. کسانی که خبره کسب و کار هستند و با تمام جزئیات و ریزه‌کاری‌های آن آشنا هستند. اما نکته این است که ارتباط برقرار کردن با این افراد کار راحتی نیست و چالش‌هایی را به همراه دارد. در این شرایط ایونت‌استورمینگ Event Storming می‌تواند روش خوبی برای حل چالش‌ها باشد. در این مقاله قصد داریم در مورد چالش‌های ارتباطی دو تیم تحلیل سیستم و تحلیل کسب و کار صحبت کنیم و روش Event Storming برای حل این چالش‌ها را معرفی کنیم. با ما همراه باشید.
چالش‌های ارتباط با خبرگان کسب و کار
اولین چالش ارتباط تیم توسعه نرم‌افزار با خبرگان کسب و کار، عدم وجود زبان مشترک بین آن‌هاست. قاعدتا این زبان مشترک، باید بیشتر به حوزه کسب و کار نزدیک باشد. چرا که توسعه‌دهنده برای آشنایی با یک کسب و کار نیاز دارد تا کلمات اختصاصی آن حوزه را بشناسد و درک کند.
چالش بعدی این است که اغلب، هر کلمه با توجه به محدوده کاربردی که دارد، معانی متفاوتی هم خواهد داشت. مثلا «مشتری» را در یک سیستم بزرگ خرید و فروش آنلاین در نظر بگیرید. مشتری از منظر نگاه تیم مارکتینگ به یک معناست و از نگاه تیم حسابداری معنای دیگری دارد. اطلاعاتی که تیم مارکتینگ از یک مشتری نیاز دارد تا بتواند پردازش‌های لازم را انجام دهد، احتمالا شامل نام و آدرس و تلفن و حوزه کاری و … می‌شود در حالی که اطلاعات مورد نیاز حسابدار، احتمالا مربوط به ریز سفارشات و تراکنش‌های مشتری است.
بنابراین ممکن است، کلمات در دامنه‌های مختلف یک سیستم واحد انتظارات متفاوتی را در ذهن ایجاد کنند. (به این محدوده اعتبار زبان در ادبیاتِ Domain Driven Design، اصطلاحاً Bounded Context یا BC گفته می‌شود. به بیان دیگر زیردامنه‌های (SubDomain) موجود در فضای مسئله (Problem Space)، در فضای راه‌حل (Solution Space) به Bounded Context تبدیل می‌شوند (برای اطلاعات تکمیلی‌تر به انتهای مقاله رجوع کنید). بنابراین مرز هر BC جایی است که مفاهیم کلمات تغییر می‌کند و راه شناخت این Bounded contextها هم تقریبا همین است.)
با شناسایی Bounded Contextها تا حدودی مشکلات مربوط به زبان مشترک حل شده و کم کم افراد توسعه‌دهنده و کسب و کار هم‌فضا شده و به زبان مشترکی می‌رسند.
چالش دیگری که در زمینه تحلیل کسب و کار و تحلیل نرم‌افزار وجود دارد این است که به دلیل مشغله متخصصین کسب و کار، معمولا زمان محدودی در برقراری ارتباط با این افراد وجود دارد. بنابراین تحلیلگر باید بتواند در این مدت محدود، ذهن او را روی مسئله و حوزه‌ای که برای تیم اهمیت بیشتری دارد، متمرکز کند و از تخصص او بهره ببرد. برای هر تحلیلگر نرم‌افزاری روشن است در چنین شرایطی این امکان وجود ندارد که از یک متخصص کسب و کار یک لیست نیازمندی طویل درخواست کند. چون به احتمال زیاد، نهایتا چیزی که نصیبش می‌شود، لیستی از راه حل‌هایی است که به ذهن آن متخصص رسیده و قاعدتا خیلی مفید نخواهد بود. در عین حال اگر از راه‌های دیگر مثل مصاحبه یا جلسات حضوری برای صحبت با آن‌ها استفاده کنیم، باز هم با چالش‌هایی مواجه خواهیم بود.
یکی از این چالش‌ها این است که این جلسات گاهی بسیار منفعالانه پیش می‌روند و معمولا یک نفر صحبت‌کننده و بقیه شنونده هستند. در طول صحبت آن یک نفر، معمولا برای بقیه حاضرین سوالاتی پیش می‌آید که برای جلوگیری از قطع صحبت ارائه‌دهنده سوال خود را مطرح نمی‌کنند و ممکن است بعداً آن را فراموش کنند.
چالش دیگر روشهای سابق در تحلیل کسب و کار این است که هر فرد با یک پیش‌زمینه ذهنی در این جلسات شرکت می‌کند. اغلب سعی می‌کند برای هر چیزی که می‌شنود یک معادل در ذهنش پیدا کند که این امر باعث می‌شود تصور کند همه چیز را متوجه شده و در مورد موارد مطرح شده سوالی نپرسد.
چالش بعدی زمانی پیش می‌آید که در جلسات، یک مسئله پیچیده را ارائه نموده و نظر همه حاضرین را در مورد آن بخواهیم بدانیم. در این حالت، ارائه مسئله پیچیده و بررسی آن از زوایای متفاوت، در زمان محدود این جلسات بسیار سخت و گاهی حتی غیرممکن است.
Event Storming؛ راه‌حلی برای هم‌ذهن شدن تیم‌های تحلیل و کسب و کار
تکنیک EventStorming یک روش تحلیل جدید است که امروزه در دنیا بسیار مورد توجه قرار گرفته است. EventStorming یک نوع کارگاه انعطاف‌پذیر است که برای تحلیل سیستم‌ها در حوزه‌های تجاری پیچیده استفاده می‌شود. ماهیت تطبیقی EventStorming اجازه میدهد تا مکالمه‌های بین رشته‌ای پیچیده بین ذینفعان با پیشینه‌های مختلف انجام شود و نوع جدیدی از همکاری فراتر از مرزهای تخصص ارائه شود. اساس این روش بر پایه دنبال کردن رفتار سیستم است و با مرکزیت قرار دادن رفتار سیستم کارکرد کلی سیستم شناخته می‌شود.
حل چالش‌ها با استفاده از Event Storming
در سال ۲۰۱۳ میلادی، آقای Alberto Brandolini روش خلاقانه‌ای برای برگزاری جلسات تحلیل کسب و کار و سیستم های پیچیده ارائه کرد. مبنای این جلسات حضور فعالانه‌ی همه‌ی افرادی است که در پروژه به نحوی شرکت دارند و در تحلیل سیستم نقش موثری خواهند داشت. این کارگاه‌ها با نام Event Storming شناخته می‌شوند.
چگونه EventStorming را اجرا کنیم؟
رویداد EventStorming در حقیقت جلساتی هستند که با حضور یک تسهیل کننده (Facilitator)، توسعه‌دهندگان سیستم، تحلیلگران و متخصصین کسب و کار برگزار می‌شود. نقش تسهیل‌کننده برای پیشبرد و به نتیجه رسیدن این جلسات بسیار مهم است.
تسهیل کننده، لزوما کسی نیست که در مورد همه چیز آگاهی دارد، بلکه کسی است که می‌داند جواب هر سوال را چه کسی می‌داند و جلسه را به سمت هرچه شفاف‌تر شدن مسائل پیش می‌برد.
در ابتدا تسهیل کننده، افراد را دعوت می‌کند که برای اولین جلسه حضور پیدا کنند. بهتر است قبل از هر جلسه به تمام مدعوین گفته شود که تمرکز روی کدام قسمت از مسئله است. این کار باعث می‌شود همه با ذهنی آماده‌تر حاضر شده و سریع‌تر در جریان قرار بگیرند.
در این کارگاه‌ها میز و صندلی وجود ندارد. در عوض یک میز بزرگ پذیرایی وجود دارد. از آنجایی که حضور مدعوین بسیار فعال و به صورت ایستاده هستند، بعد از گذشت مدت زمانی باید حتما وقت استراحتی در نظر گرفت. استاندارد زمان این جلسات دو ساعت و بهتر است از این مقدار کمتر یا بیشتر نشود. چرا که بیشتر بودن این زمان بهره‌وری را پایین آورده و کمتر بودن آن هم باعث می‌شود بحث تا جای مناسبی پیش نرود.
در طی این جلسات به یک دیوار بزرگ نیاز است و مقداری کاغذ یادداشت برچسبی (Sticky note ) با رنگهای استاندارد، که از هر رنگ برای نشان دادن چیزی استفاده می‌شود. خوب است بدانید که مبنای این روش رفتار سیستم است. یعنی در اصل شناسایی رویداد‌ها (ٍEvent). بنابراین بعد از شناسایی حوزه‌های (Context) مختلف، سراغ رویدادهایی می‌رویم که در هر حوزه اتفاق می‌افتد.
هر شخص می‌تواند یک یا چند رویداد که در حوزه مشخص اتفاق می‌افتد را شناسایی کرده و در کاغذ یادداشت برچسبی مربوط به آن حوزه نوشته و آن را به دیوار بچسباند. رویداد‌ها با فعل گذشته نوشته می‌شوند. زیرا نشان‌دهنده اتفاقی هستند که در گذشته افتاده و خبر آن اکنون به دست ما رسیده است.
بعد از شناسایی تمام رویدادهایی که در حوزه مشخص اتفاق می‌افتند، نوبت به سوال‌ها می‌رسد. تسهیل‌کننده از یک رویداد شروع کرده و سوال مطرح می‌کند که بعد از این رویداد چه اتفاقی می‌افتد. این پروسه تا زمانی طول می‌کشد که هر رویداد یک چرخه کامل را طی نموده و به انتها برسد و در نهایت نتیجه‌ای برای آن حاصل شود. هیچ رویدادی نباید باقی بماند که ندانیم زمانی که رخ داد، نتیجه نهایی سیستم در مورد آن چه خواهد بود. به طور کلی از نظر فنی Event Storming بر روی چیزهایی تمرکز می‌کند که در حال حاضر در فرایند کسب و کار اتفاق می‌افتد؛ این چیزها به عنوان رویداد‌ها (Event) شناخته می‌شوند.
معانی و رنگهای کاغذ یادداشتهای برچسبی
رنگ آبی، Command را نشان میدهد. commandها دستورالعمل‌هایی هستند که برای سیستم صادر می‌شوند تا سیستم به ازای آن‌ها اقدامی انجام داده و بعد از این اقدام، سیستم به وضعیت (state) جدیدی می‌رسد. این commandها می‌توانند از کاربر یا سیستم یا رویداد دیگری ناشی شوند. به عنوان مثال Create New Loan Application یک command است.
رنگ نارنجی، Event را نشان میدهد. رویداد‌ها اتفاقات مهمی هستند که در پردازش commandها در سیستم اتفاق افتاده است. معمولا یک رویداد باعث تولید رویداد‌های جدید یا تغییر وضعیت رویداد‌های موجود می‌شود. مانند «حساب برداشته شد» که با فعل گذشته نوشته می‌شود. کلید اصلی EventStorming، شناسایی رویداد‌هاست. معمولا متخصصین کسب و کارها پیشرو شناسایی رویداد‌ها هستند.
رنگ برنز، Aggregate را نشان میدهد. یک Aggregate یک Entity کسب و کار سطح بالاست که شامل مجموعه‌ای از رویداد‌هاست یا مجموعه‌ای از رویداد‌ها آن را ایجاد می‌کنند و با اسم نمایش داده می‌شوند؛ به عنوان مثال «ثبت نام مشتری» یک Aggregate است.
رنگ صورتی، External System را نشان میدهد. یک External System، نشان دهنده سیستم‌های درگیر در دامنه سیستم بوده و ممکن است به سیستم ما command بفرستند یا دریافت کنند. به عنوان مثال، زمانی که سیستم، امکان پرداخت الکترونیکی دارد، درگاه بانکی یک سیستم خارجی برای سیستم ما محسوب می‌شود. External systemها می‌توانند از نوع شخص ثالث باشند یا سرویسی از یک سیستم درونی که با برنامه ما در تعامل است.
رنگ زرد، User را نشان میدهد. منظور از User همان کاربران انسانی سیستم هستند که در این فرایند دخیل بوده و ممکن است یک شخص یا یک تیم نیز باشند. Sticky noteهای زردرنگ نشان می‌دهند که روند کاری یک فرایند تجاری چقدر می‌تواند بر اساس تعداد بخش‌های درگیر و میزان رفت و برگشت پیچیده باشد.
رنگ سبز، Read Model را نشان میدهد. Read Model، نشان دهنده داده‌هایی است که ممکن است برای یک کاربر یا سیستم در تصمیم‌گیری، حیاتی باشد. این مورد زیاد استفاده نمی‌شود، اما معمولا برای تاکید بر داده‌هایی که کاربر می‌بیند می‌تواند مفید باشد.
رنگ طوسی، Policy را نشان میدهد. Policyها، استانداردها یا قوانینی هستند که باید اجرا شوند.
Bounded Context چیست؟
مرز فیزیکی و منطقی حول یک دامنه‌ی (یا زیردامنه) به هم پیوسته و سازگار است که دسته ای از Entityها، value Objectها، Aggregateها، سرویس‌ها و Repositoriهای متعلق به آن را کپسوله می‌کند.
اطلاعات فنی بیشتر در رابطه با Bounded Contextها:
- هر BC به عنوان یک واحد مستقل شناخته می‌شود و Domain Model مخصوص خود را دارد.
- الگوهای طراحی و معماری در هر BCمی‌تواند (بسته به ماهیت آن) متفاوت باشد. مثلاً ممکن است در پیاده‌سازی یک BC، از معماری لایه‌ای استفاده کنیم و در دیگری از الگوی CQRS.
- الزامی به وجود دیتابیس‌های جداگانه برای هر BC نیست.
سخن پایانی
همانطور که گفتیم یکی از چالش‌هایی که در روند توسعه نرم‌افزار وجود دارد، نبودن زبان مشترک بین تیم‌های فنی و کسب و کار است. برای رفع این چالش روش جدیدی به نام Event Storming به وجود آمده است که تا حد خوبی این چالش را حل می‌کند. در این مقاله در مورد Event Storming صحبت کردیم و تلاش شد یک دید کلی در مورد آن در اختیار شما قرار دهیم. شما هم اگر تجربه‌ای در مورد این موضوع دارید، در بخش نظرات با ما در میان بگذارید.
منابع:
دیدگاهتان را بنویسید