چه ارتباطی بین DDD و اجایل وجود دارد و چرا آشنایی با DDD برای تیمهای اجایل مفید است؟
Rohalah Delpak
هر چند سال به سال اجایل در بین توسعه دهندگان نرم افزار از اقبال بیشتر و جایگاهی محکمتر برخوردار می شود، اما مفاهیم و اصولی که مکمل فعالیتهای یک تیم اجایل و قدرت دهنده آن هستند به اندازه کافی مورد بررسی و توجه قرار نمی گیرند – بین اجایل کارهای ایرانی - و این بیم می رود که اجایلیتی به تدریج ناکارآمد جلوه کند و تبدیل شود به شیری بی یال و دم.
تفکرDDD هم از همین دست موضوعاتی است که می تواند یک تیم اجایل را اجایل تر کند و به تقویت میزان پایداری به اصول و شاخصهای اجایلیتی در تیم، بینجامد. ولی چگونه؟ فرهنگ اجایلیتی و فضای فکری DDD چه خویشاوندی با هم دارند؟ ارتباط آنها چیست؟
اول باید بدانیم که یک تیم اجایل، وقتی اجایل است که به ارزشهای زیر وفادار بماند:
· (Individuals and interactions over processes and tools) ارتباط با اشخاص را بر استفاده از ابزار ترجیح می دهیم.
· (Working software over comprehensive documentation) نرم افزاری کارآمد را بر مستند سازی ترجیح می دهیم.
· (Customer collaboration over contract negotiation) همکاری مشتری را بر تقید به مفاد قرارداد ترجیح می دهیم.
· (Responding to change over following a plan) آماده پذیرش تغییرات آینده هر چند دیرهنگام، هستیم.
منبع: http://agilemanifesto.org/
حال میپردازیم به اینکه خویشاوندی این اصول با DDD در چیست؟
از اولین اصل شروع می کنیم:
(Individuals and interactions over processes and tools)
تعامل با افراد درگیر در پروژه ارجحیت دارد به استفاده از ابزارها.
پنج نفر توسعه دهنده را در نظر بگیرید که در یک اتاق دور هم نشسته اند و بهترین ابزارها را در اختیار دارند ولی بحث و گفتگویی بین آنها وجود ندارد و هر کدام در عالم خویش مشغول به کار خودش است.
در مقابل پنج نفر توسعه دهنده دیگر را در نظر بگیرید که حداقلی از ابزارهای مورد نیاز خود را در اختیار دارند ولی تعامل قوی و مطلوبی بین آنها و مشتری برقرار است و جلسات مستمری با مشتری برگذار می کنند. ایده هایشان را مطرح می کنند و توافقاتشان را بین هم دیگر به اشتراک می گذارند.
کدام تیم موفق تر عمل خواهد کرد؟
DDD با این اصل سازگار است به این نحو که تاکید می کند همه افراد درگیر پروژه مانند برنامه نویسان، تست کنندگان، مشتریان، مدیران، مستند نویسان و ... در تولید زبانی مشترک که اصطلاحا (Ubiquitous language) نامیده می شود "فعالانه" عمل کنند و آن را صحبتهای خود، کد، نمودارها و نوشته ها استفاده کنند. طبیعی است که خلق و بسط و تقویت این زبان مشترک حاصل نمی شود جز با "تعامل" با همه اشخاص درگیر پروژه. فعالیتهایی مانند جلسات صبحگاهی - روزانه، Spike، Iteration Zero, Sprint Planing همگی با تاکیدات DDD همخوانی دارند.
در مورد (Ubiquitous language) قبلا نوشته ام. از اینجا بخوانید.
اصل دوم: Working software over comprehensive documentation
فراموش نکنیم که هدف اصلی از توسعه نرم افزار، تولید یک نرم افزار است نه تولید مستندات. در غیر اینصورت باید گفت کار ما Documentation development است نه Software development!
DDD با این اصل هم سازگار است به این نحو که در DDD تمرکز اصلی بر غلبه بر مشکلاتی است که در دامین (Domain) وجود دارد. این مشکلات همان هایی هستند که اساسا مشتری برای حل آنها می خواهد هزینه پرداخت کند. در اجایل کوشیده می شود که فعالیت ها معطوف به خلق بیشترین ارزش برای مشتری شوند و این هدف از پایه های فکری DDD است.
(Eric Evans : Focus on the Core Domain)
با الهام از آموزه های DDD می توان سریعتر و دقیقتر انعکاسی از "دامین" را در "مدل" بوجود آورد. هر چند مدل اکتشافی است اما همین مدلهای اولیه با مشارکت متخصصان دامین به سرعت تبدیل به بخشی از محصول نهایی خواهند شد که برای مشتری ارزشمند خواهند بود. توجه کنید که مهم نیست شما چقدر برای طراحی مدل هایتان وقت صرف می کنید. قطعا مدلهای شما نیاز به بهبود خواهد داشت. بهبود مدل هم میسر نمی شود مگر با دریافت بازخوردهای مشتریان در یک فرآیند توسعه Incremental.
اصول سوم و چهارم: Customer collaboration over contract negotiation و Responding to change over following a plan:
فقط مشتریست که می تواند بگوید نیازش چیست. درست است که توان بیان عالی نیازمندی خود را ندارد، درست است که ممکن به خطا برود، درست است که فکر و ذهن مشتری در حال تغییر است ولی اینها همگی واقعیتهای کار ما هستند.
البته داشتن قرار داد با مشتری مهم است تا مسئولیتها شفاف شوند ولی قرار داد جایزگزینی برای گفتگو نیست. توسعه دهندگان موفق با مشتریان خود به گفتگو می نشینند و از این راه به کشف نیازهای او می رسند و البته به مرور زمان مشتری را هم آموزش می دهند.
اما این اصل با DDD چه خویشاوندی دارد؟ در DDD هم تاکید بر شناخت مسائل حوزه کاری (Domain) با مشارکت فعال مشتری شده است. توجه کنیم که توسعه نرم افزار یک فرآیند مکاشفه ای است. نرم افزار کامل نمی شود. نیازمندیها کشف می شوند. به همین دلیل فکر اینکه در قالب قراردادی چفت و بست دار پروژه ای را آغاز کنید و با رضایت کامل مشتری به پایان برسانید، حداقل به گواهی تجربه، بسیار نادر است. DDD ذاتا بر اکتشاف بنا نهاده شده است تا در طی یک فرآیند Iterative به اکتشاف بپردازد و بصورت Incremental به حل مشکلات دامین بپردازد. اما منبع اکتشاف چیست؟
مسلما: Domain. دانش دامین در اختیار کیست؟ Domain Expert . این یعنی اینکه باید با Domain Expert تعامل داشت. در فریم ورکهای اجایل معادل متخصص دامین، نقشهایی مانند صاحب محصول یا On-site Customer وجود دارد. در DDD تاکید شده بر اینکه دانش دامین تکه تکه به دست می آید و هر بار کاملتر از قبل می شود. نگران اکتشافی بودن دامین نباید بود. بلکه باید سازوکاری تدارک دید تا همواره مدل و دامین با هم Sync نگه داشته شوند(Refactoring). در DDD برای حل این مسئله مجموعه ی سازگاری از بهترین قواعد و تجربیات وجود دارد که می توانند به شدت پیچیدگیهای دامین را کاهش دهند و نهایتا بر مشکلات دامین چیره شد.
نتیجه:
همه افراد درگیر پروژه از مدل و سازوکار آن مطلعند و نسبت به کارآمدی آن مسئولند. این یک تیم وافادار به DDD است. این یک تیم وفادار به اجایل است.
My profile in Linkedin