EDD: رقصی هنرمندانه میان Domain Expert و Developer

3

خلاصه:

توی این پست می‌خوام در مورد تجربه‌ام از ورکشاپ EDD که توسط مسعود بهرامی برگزار شد بنویسم. اگه با دامین‌های پیچیده مالی مثل حسابداری و حقوق و دستمزد سر و کار دارین و نمی دونید از کجا شروع کنید و پروداکت منیجر، Domain Expert و دولوپر هستین این پست برای شماست.

اگه میخواین درمورد EDD بیشتر بدونید قبل از این مطلب می‌تونید به این لینک ها مراجعه کنید:

https://masoudbahrami.substack.com/p/exploratory-domain-discovery-edd

https://masoudbahrami.substack.com/p/the-heart-of-exploratory-domain-discovery

https://www.youtube.com/watch?v=7vPq5qjI21s&t=1519s

جمعه 7 دی ورکشاپی به اسم Exploratory Domain Discovery توسط مسعود بهرامی برگزار شد، ورکشاپ EDD یک رویکرد Modeling Collaborative یا به اختصار CoMo است. در اصل CoMo شبیه مانیفست است (یکسری principle) و رویکردهایی/کارگاهایی که این اصول را در هسته‌ خودشون دارند را به عنوان یکی از روش ها، رویکردها، ابزار و کارگاه های رسیدن به modeling collaborative and designing به حساب میاریم. EDD رویکردی هست که از نقطه آغاز به کمک Collaborative Modeling انجام میشه، کار گروهی خیلی اهمیت برجسته‌ای تو این مدل طراحی داره و ورکشاپ هم به این روش پیش رفت.

پرده اول

اولین کاری که انجام دادیم این بود که به دو گروه تقسیم شدیم، و یه برگه بزرگ سفید جلوی ما گذاشتن و ازمون خواستن که بدون اینکه دستمون رو برداریم یه طرحی رو بکشیم و خودکار رو به نفر بعدی بدیم، تیم‌ها شروع کردن به طراحی، هر کس یه شکلی رو انتخاب می‌کرد و سعی می‌کرد به شکلی اون رو تموم کنه که نفر بعدی بتونه شکل رو ادامه بده، به همین دلیل طرح‌های خلاقانه و بامزه‌ای ایجاد شد. این تمرین یه abstraction خیلی ساده و واقعی از اتفاقی هست که تو تیم‌های نرم‌افزاری می‌افته، موقعی که شروع به تعریف داستان بیزینس می‌کنن و موقعی که پروژه استارت میخوره همه ما چیزی رو تحویل می‌گیریم و ادامه اون رو می‌بریم جلو، این وسط فیلتر‌های زیادی وجود داره، چالش‌ها و استراتژی‌های مختلفی هم وجود دارن که همه در نهایت روی طرح نهایی تاثیرگذار هستن.

پرده دوم

فاز بعدی، پیدا کردن main point بود از روی داستانی که تعریف می‌شد، یه داستان ساده از اتفاقات روزمره و پیدا کردن هدف اصلی اون.

داستان ما این بود: شهین در یک آپارتمان قدیمی زندگی می‌کرد که حیاط پشتی کوچکی داشت این حیاط سال‌ها بود که به حال خود رها شده بود پر از علف‌های هرز و زباله. شهین که عاشق گل و گیاه بود تصمیم گرفت این وضعیت را تغییر دهد او با صرف وقت و انرژی زیاد علف‌های هرز را کند زباله‌ها را جمع‌آوری کرد و خاک را آماده کرد سپس با خرید چند گلدان گل و گیاهان مختلف باغچه کوچکی را در آنجا ایجاد کرد، او حتی یک نیمکت کوچکی هم در آنجا قرار داد سپس همسایگان به این باغچه زیبا جذب شدند و شروع به کمک کردند آن‌ها گل‌های جدید کاشتند، به گیاهان آب دادند و حتی ساعاتی را در آنجا به استراحت و گفتگو می‌پرداختند حیاط پشتی آپارتمان که زمانی مکانی متروکه بود حالا به ‌مکانی دل‌نشین و گردهمایی همسایگان تبدیل شده بود.

نکته اصلی این داستان به نظر شما چی بود؟ تو کامنت بهم بگین.

بعد از گفتگو با اعضای تیم هر کسی نظر خودش رو گفت : حل مسئله، تبدیل تهدید به فرصت، رسیدن به حال خوب پس از تحمل سختی، دغدغه‌مند، نیازمندی و هدف، مسئولیت‌پذیری و ... و در نهایت کلمات کلیدی صحبت های همه رو در قالب یک جمله بیان کردیم.

بخش بعدی این بود که یه جمله نوشته شده بود و باید برای اون جمله یه داستان تعریف می کردیم:

Leave the world a little bit kinder than ya found it.

اشتراکاتی که بین این داستان‌ها وجود داره این هست که میخوایم یه point رو به کسی برسونیم و اون نکته رو در قالب یک story و یک context سعی می‌کنیم منتقل کنیم به این هدف که اون point درست منتقل بشه، گاهی اوقات اون point رو داریم و سعی می‌کنیم از اول جملاتی رو طوری بچینیم که درست مفهوم رو منتقل کنه. 99% هر داستانی context هست! تو کتاب clean code هم به این quote بالا اشاره شده، سعی می کنیم کد رو طوری refactor کنیم که جای بهبود برای بعدا هم داشته باشه.

Roles

نکته: نقش هایی که تو این ورکشاپ بیان شده در واقع نقش هایی هستند که برای ورکشاپ EDD نیاز داریم و این نقش‌ها ارتباط مستقیمی با خود CoMo ندارند و همینطور برعکس، بخشی از رویکردهای CoMo هم ممکن هست بعضی از این نقش‌هایی که در کارگاه معرفی میشه رو داشته باشن یا نداشته باشن.

نقش‌هایی که در EDD وجود داره این‌ها هستن:

1. Facilitator

پیشنهاد موکد میشه که تمام تمرکز یک فرد روی همین نقش باشه و در زمان برگزاری جلسه این فرد کارش facilitate کردن جلسه هست و از Practitionerها که در ادامه می‌گیم باید جدا باشه و همینطور خود این فرد باید قبلا تجربه شرکت کردن در کارگاه EDD رو داشته باشه خروجی جلسه رو بدونه و درک کنه که اعضای تیم به چه هدفی دور هم جمع شدن چون هدف جلسه بر گزاری EDD نیست. هدف رسیدن به تصویر بزرگ‌تر و main point هست این فرد می‌دونه که artifact و خروجی اون کاری که قرار هست انجام بشه چی هست و باید اون Practice که انجام میشه رو به اصطلاح روش سوار باشه و بدونه چطور انجام میشه و از اون مهم تر خیلی مهم تر این هست که دنبال چی هستیم و اگر فکر کرد رویکرد و سازوکار EDD به هر دلیلی به درد جلسه نمی‌خوره بهتره رویکرد دیگری رو اتخاذ کنه.

2. Practitioner

در اصل بازیکنان اصلی بازی توی EDD هستند و کسایی هستن که اون داستان رو تعریف می‌کنن تو دنیای software وجود دو تا آدم خیلی مهم هست آدم هایی که سوال خوب می تونن بپرسن که کسایی هستن که میخوان یه کاری رو انجام بدن و آدم‌هایی که جواب سوالات رو دارن و فقط کسایی نیستند که نرم‌افزار رو تعریف می‌کنند بلکه همه کسایی که توی جلسه هستند یا همه ذینفعان پروژه باید پرکتیشنر باشند مثلا متخصص دامنه، UI, UX, QA و ...

3. Scribe

میرزا بنویس یا Scribe کسی هست که اون نکته ها رو می نویسه طی جلسه، توی Event Storming نقش مهمی هست و نقش جداگانه ای نیست که فقط یک نفر اون رو بر عهده بگیره. دلیلش هم اینه که توی Event Storming همه دارن به صورت فعالانه مشارکت می‌کنن و نکات رو روی sticky note می‌نویسن ولی توی Domain Story Telling یک نفر این کار رو انجام می‌ده.

4. Time Tracker

نقش Time Trackerبیشتر از این جهت مهم است که ما معمولا یک تایم2 الی 3 ساعته برای همچین جلساتی داریم. آدمهایی که دعوت میشن همیشه در دسترس نیستن، پس بهتره برای هر راند EDD یک تایم مشخص داشته باشیم. این تایم باکس بودن کمک می‌کنه که روی موضوعاتی که بحث برانگیز هستند ولی ممکن هست که مهم نباشند و جزئی باشن، خیلی توقف نکنیم. اونها رو روی کارتهای قرمز رنگ می‌نویسیم و رد می‌شیم. هدف این نیست که صد در صد درمورد همه چیز به اجماع نظر برسیم. مهمترین چیزی که اگر بهش برسیم می‌تونیم بگیم اون هدف رو زدیم حرکت از unknown به known هاست. این knownها می‌تونه سوالاتی باشه که جوابشون رو نمی‌دونیم. ولی توی ماتریس آیزنهاور ما از unknown رسیدیم به known، پس حتی می‌تونیم بگیم هورا :)

مقدمه ای بر EDD

یکی از toolهای CoMo رویکرد EDD هست.

1. Specification by example

آوردن example توی همه (تقریبا) راندهای فایت کردن توی EDD ضروری است. بخاطر همین یکی از کارتهای استیکی نوت، یعنی یکی از بیلدینگ بلاک‌های اصلی توی EDD اختصاص داده شده به همین exampleها هست. برای مثال به جای این که یک feature رو به صورت مستقیم توضیح بدیم میشه اون ها رو به صورت کلی گفت و example اجرا (run) کرد تا اون چیزهایی که باید درمورد اون فیچرها گفت رو بگیم و برای اینکه مطئن بشیم که همه متوجه موضوع شدن سعی می کنیم example اجرا کنیم چون این مثال ها to the point, concrete هستن و خیلی راحت تر می‌تونیم متوجه بشیم که نکته رو فهمیدن همه یا اینکه منظور ما رو اشتباه متوجه شدن و تو هر مرحله ای که داریم explore انجام می‌دیم اون example رو اجرا می‌کنیم.

تولید و توسعه نرم‌افزار یک فرایند یادگیری هست.

2. Merge people, not split them!

تیم اسکرام و اعضای تیم توسعه همه توی یک زمین بازی می‌کنیم، به جای جدا کردن تیم از همدیگه تیم ادغام بشه و سیستم نرم افزاری شکسته بشه

3. Multi-Layer Domain

فضای مسئله یک فضای multi layer هست و گاهی اوقات تو دامین های پیچیده ای مثل Payroll (حقوق و دستمزد) و حسابداری ما ممکن هست تبدیل به متخصص اون دامین بشیم تا بتونیم نرم افزاری رو توسعه بدیم، در دامین هایی که با Customer درگیر می‌شیم به نوعی مشتری هم جزء اون سیستم هست یعنی B2C و اگه دولوپر نباشیم باز هم متوجه اون سیستم می شیم مثل خرید اینترنتی و ...

4. Forget about the depth-first approach!

رویکردی که به صورت طبیعی مغز داره به این شکل هست که دوست داره به صورت عمیق تمام ارتباط‌ها و دانش های پنهان شده درمورد یه موضوع رو بدونه و Deep بشه ولی برای حل مسئله این رویکرد خوبی نیست. یه جمله ای هست که میگه اگه میخواین یک چیزی رو به کسی نگین دو حالت داره یا مستقیم بگین که نمی گین یا اینکه اونقدر اطلاعات بدین که کسی متوجه نشه آخرش چی شد و یه دریایی از اطلاعاتی رو بدین برای ما که تو software هستیم هم این اتفاق می‌افته و نمی‌دونیم اصلا اصل مسئله چی بوده و از کجا باید شروع کنیم.

توی رویکرد EDD ما سعی می‌کنیم برعکس این مسیر رو بریم و سعی می‌کنیم توی اون مسئه ای که داریم explore می‌کنیم Breadth First Exploration هست، توی این رویکرد سعی می کنیم تو اون فضایی که داریم explore می‌کنیم Abstraction رو تو اون level حفظ کنیم و هر جایی که نیاز بود وارد جزئیات می‌شیم و هر جایی هم که نیاز نبود وارد جزئیات نمی‌شیم.

5. Start from the end: focus on the desired goal.

سوالی که اول از همه از خودمون می پرسیم این هست: تهش که چی؟ یکی از فلسفه‌های متمایز کننده‌ای که توی EDD داریم این مورد است که ما با یک end desired goal یا end desired point توی محصول شروع می‌کنیم، این به ما کمک می کنه که point اصلی رو شناسایی کنیم و سعی کنیم ادامه مراحل و context رو بر اساس اون point بچینیم، هم کسی که کار توسعه انجام میده هم کسی که کار محصول انجام میده. بعد شروع می‌کنیم عقب عقب برمی‌گردیم و داستان رو جوری می‌چینیم که بتونیم به این end desired goal برسیم. احتمالا این جمله رو از استیو جابز شنیده باشین:

You can't connect the dots looking forward, you can only connect them looking backwards

برداشت‌های مختلف می تونه طراحی رو عوض کنه، اگه فرمول اصل موضوع payroll باشه همه چیز براساس اون جلو میره ولی اگه به این نتیجه برسیم که فرمول اصل موضوع این سیستم نیست و یک context برای چیز دیگه هست، طراحی عوض میشه یا اگه تو سیستم حسابداری متوجه بشیم که Account tree اصل موضوع نیست دوباره طراحی عوض میشه.

6. Keep the abstraction at the level of exploration

وقتی هنوز روال کلی چگونگی انجام یه کاری رو خبر نداریم ولی روی یه موضوعی سریعا deep می‌شیم و بعدا که بریم جلو باید برگردیم عقب دائما تا مرور کنیم و اطلاعات زیادی سر وقت ما میاد و باید این ها رو متوجه شیم نکته اینجاست که deep شدن بد نیست ولی باید در تایم مناسبی اتفاق بیافته.

یه مسئله واقعی:

Practicing EDD in Accounting

براساس داستانی که Domain Expert برای ما تعریف می‎‌کنه باید main point و اجزای اصلی سیستم رو پیدا کنیم:

• به یه بخشی نیاز دارم که بتونم انواع حساب رو اونجا تعریف کنم مثل حساب های دارایی و دریافتنی و پرداختنی.
• میخوام سلسله مراتب داشته باشه و انواع حساب ها رو دسته بندی کنم.
• میخوام روی سندها تاریخ بزنم و از تراکنش ها اکسپورت بگیرم.
• می خوام مغایرت های بانکی رو داشته باشم و سند اصلاحی بزنم.
• گروه حساب داشته باشم یعنی گروه حساب معین و کل و بتونه اون حساب ها رو به تفصیلی ها وصل کنم.
• گزارش بگیرم مثل گزارش سود و زیان و Balance sheet.
• دوره مالی میخوام تعریف کنم که یه آغاز و پایان داره.
• بتونم opening balance تعریف کنم.
• همینطور Journal entry های سند‌ها رو به دفتر کل بفرستم.
• سند بزنم و اون شامل اطلاعات سند مثل شماره و مبلغ و هدر و توضیحات هست.

7. Basic information

پیدا کردن نقطه شروع تو این مکالمه می تونه سخت باشه، به نوعی مسئله مرغ و تخم مرغ هست و میزان اطلاعات عظیمی سمت ما میاد. کاری که انجام میدیم این هست که با اطلاعات پایه شروع می کنیم و sequentially به مسئله نگاه می‌کنیم و خلاصه اون این هست که تا وقتی که نتونم حساب گروهی تعریف کنم نمی‌تونم حساب کل تعریف کنم و تا حساب کل تعریف نکنم نمی‌تونم حساب معین تعریف کنم و الی آخر.
جلوتر که می‌ریم شروع به تعریف سند می‌کنیم ولی نهایت چیزی که تیم متوجه میشه mechanical هست! ما می‌تونیم فضای مسئله رو کنترل کنیم: مثلا تو این مرحله شماره یونیک بودن حساب ها اهمیتی نداره من اول باید بفهمم نقطه کانونی چی هست و چی تو حسابداری مهم هست.

اگه حسابداری هم یه story باشه پس احتمالا یه main point داره و بقیه context هستن سوال اینجا هست که اون نکته اصلی چی میتونه باشه: معمولا پوینت اصلی اینجا سند میشه که به حساب وصل میشه و معمولا هم حساب معین میشه.

8. Circular pattern

تو این مرحله دنبال pattern هستیم که داره تکرار میشه و اگه مسئله رو برای اون حل کنیم احتمالا برای کل دامین مسئله حل میشه و معمولا توی این پترن، زمان نقش مهمی رو داره و دائما تکرار میشه مثلا : سال، روز و ... توی سیستم حسابداری هم یه سری چیزها هست که به ما سرنخ میده مثل Financial Year که مشخصا داره درمورد سال صحبت می‌کنه و زمان خیلی اینجا دخیل هست. توی این سال مالی یه شروع و پایان هست. این سرنخ هایی که پیدا کردیم رو شروع می کنیم visualize می کنیم و می گیم یه محور زمان داریم و طبق صحبت ها می تونیم بگیم دوره مالی و میایم درمورد یه دوره مالی خاص صحبت می کنیم مثلا دوره مالی 1402 و scope رو کوچک تر می‌کنیم، و یه سری حالت های exceptional رخ میده که درمورد این ها نباید توی این لایه اول از abstraction صحبت کنیم این که افتتاحیه دوره مالی اولیه با بقیه متفاوت هست رو بعدا درمودش صحبت می کنیم شاید جلو برم بخوام یه مدل دیگه این رو طراحی کنم.

و هر دوره مالی به یه ژورنال وصل میشه و توی هر ژورنال لیستی از تراکش داریم و هر تراکنش شامل یه سری entry هستن (article) که هر کدوم این ها به یک حساب معین وصل می‌شن و اگه این تصویر درست بود بعد سراغ capture کردن اتفاقاتی می‌ریم که توی این دامین افتاده و ممکن هست جزئیاتی مثل Debit Credit و اینکه تراکنش حداقل دو تا حساب داره هم مطرح بشه ولی تو این مرحله این‌ها اصلا برای ما اهمیت نداره چون این‌ها Business rule هایی هستن که اگه بخوام فردا پیاده سازی‌اش بکنم، میرم سمتش. و تو این مرحله سراغ main point میریم که از کجا وارد این دامین بشیم دنبال اون سرنخ ها هستیم.

آخر این مسئله این هست که یک journal وجود داره و هیچ جزئیاتی ازش نمی دونم و به این میگم Domain Concept. مرحله بعد تو این journal سندها میان اینجا پست میشن پس یه سری Transaction اینجا داریم و این تراکنش ها خودش یه سری حساب معین داره subledger و ارتباط بین این ها رو اخر به اول مشخص می‌کنیم:

پس journal در واقع میشه: ثبت کردن تراکنش های حسابداری.

تر اکنش: هر کدوم از این تراکنش ها حداقل دو حساب معین رو درگیر می‌کنه

و بعد از اون پراپرتی های این ها رو اضافه می‌کنیم:

• این جورنال شامل یه سری صفحه، تاریخ و یه سری سند میشه.
• تراکنش شامل: تاریخ، entry, مجموع Debit Credit میشه و تمام جزئیات این سند هم لازم نیست بنویسیم.
• حساب معین هم معمولا شامل یه کد و یه Title هست.

توی این لول از abstraction وقتی داریم داستان رو تعریف می کنیم باید make sense کنه و کنار این جزئیات یه سری example هم می‌نویسیم و معمولا Domain Expert اینجا می تونه راهنمایی کنه.

ژورنال به سال 1402 وصل میشه و صفحات اون ژورنال و تاریخ‌شون رو می‌نویسیم پس سندهایی که تو این ژورنال هستن و مربوط به سند 1 هستن تو صفحه 1 هستن و به همین ترتیب، داخل سند هم Debit, Credit هستن.

درمورد تراکنش هم یه شماره سند براش میخوره شماره سند 1 مثلا و یه تاریخ صدور براش می‌خوره با جزئیاتی مثل حقوق کارمندان و یه حساب دیگه هم داریم حساب بانکی که منظور ما میشه مثلا 2 میلیارد میشه پول کارمندان که از حساب بانکی پرداخت میشه.

نکات کلی

• اینجا ممکن هست سوال‌های زیادی داشته باشیم ولی باید سوال‌مون رو نگه داریم تا بریم جلو و مسئله برای ما واضح تر بشه.
• ممکن هست Business rule هایی اینجا باشه که اون هارو اینجا capture می‌کنیم مثل هر سند حداقل دو سند دارد.
• اینجا ممکن هست تفصیلی هم پیش بیاد که حداقل دو تا معین رو درگیر می‌کنه ولی یه مرحله پایین تر میشه و فعلا وارد این موضوع نمی‌شم و تو لایه abstraction بعدی می‌ریم سراغش.

تو این مرحله منظور از هر کدام از این مفاهیم رو متوجه شدیم و معنی هر کدوم رو کنارشون یادداشت می‌کنیم و یه زبانی رو استفاده می‌کنیم و unified می‌کنیم که همه جا این رعایت بشه، توی توسعه، داکیومنت، دامین و فیگما و API هم همین زبان باشه.

Recap

یه پترن رو پیدا کردیم به اسم دوره مالی و اتفاقاتی که اونجا افتاده بود رو پیدا کردیم و ارتباط بین اون ها رو پیدا کردیم و جزئیات شون رو یادداشت کردیم و یه بار باید این داستان خونده بشه و اگه چیزی از قلم افتاده که مهم هست اضافه بشه تا اینجا این رو داریم:

یه ژورنال داریم توی هر دوره مالی، ژورنال یه سری تراکنش داره و هر تراکنشی هم حداقل دو تا حساب معین رو درگیر می‌کنه. تا اینجا مرحله اول رو رفتیم جلو ولی چطور بریم سراغ مرحله دوم و روی کدوم از این‌ها عمیق بشیم؟ جواب این سوال خیلی مهم هست چون اگه روی همه اینها عمیق بشم دارم دوباره از abstraction خارج میشم و نمیخوام دوباره از دوره مالی شروع کنم دوباره این اتفاق می‌افته، توی مرحله دوم باید سرنخی رو پیدا کرد که به ما کمک کنه روی دامین درستی عمیق بشیم.

Value Stream

کل ارزشی که تو اون سیستم هست حول چه چیزی می چرخه؟ توی حسابداری یه value stream مبتنی بر زمان داریم که باید از اول تا آخر انجام بشه که بگیم مسئله حسابداری انجام شده.

Good questions

بیشترین فعالت تکرار‌شونده تو این دامین چی هست؟ ثبت سند

Walking skeleton metaphor

یک metaphor داریم از Alistair Cockburn که میگه: توی sprint که اجایلی‌ها ست می‌کنن به عنوان sprint zero بورد رو ستاپ می‌کنن و آدم ها رو جمع می‌کنن، و ما قرار هست یک محصولی رو توسعه بدیم می‌تونیم فکر کنیم یک آدمی هست که قرار هست توسعه بدیم و اون آدم رو شبیه اسکلتی بهش نگاه می‌کنیم که می‌تونه راه بره فقط در مرحله اول، یک بار چیزی که قرار هست دولوپ کنیم رو تصور می‌کنیم و اگه کلیات کار اوکی بود اون رو توسعه می‌دیم.

تو این مرحله ما یه سیستم پیچیده رو به حالت ساده شکوندیم و main point رو پیدا کردیم، تو این مرحله ما اصلا کاربر رو وارد بازی نکردیم و سیستم رو بررسی کردیم.

بخش اول تموم شد تو بخش دوم تجربه خودم رو در استفاده از این رویکرد می‌گم.

خوشحال میشم نظرات تون رو بدونم، مرسی که خوندید.