مساله شمع، مساله زبان: اهمیت زبان در حل مسایل پیچیده.

 
کارل دانکر (Karl Duncker)، - روان‌شناس آلمانی – در سال ۱۹۴۵ آزمایشی ترتیب داد که نتایجش تا دهه‌ها بعد مورد توجه دانشمندان علوم رفتاری قرار گرفت. آزمایشی به نام Candle Problem که دریچه‌های تازه‌ای به دنیای پیچیده‌ی انگیزش، شناخت، قضاوت و تصمیم‌گیری گشود.

این آزمایش به اختصار این‌گونه است که یک جعبه کبریت، یک جعبه پونز و یک شمع به شرکت‌کنندگان داده می‌شود و از آنها خواسته می‌شود که سعی کنند شمع را جوری به دیوار متصل کنند که وقتی روشن است، قطرات شمع آب شده روی میز نریزد. (شکل زیر).

راه حل بهینه برای این مساله این است که جعبه پونز خالی شود و آن را به دیوار وصل کرده و شمع را در آن قرار داده و روشن کنیم.

اما نتیجه آزمایش غیرمنتظره بود! اغلب شرکت کنندگان برای حل این مساله راه‌هایی یافتند که هرچند عجیب و خلاقانه‌ بودند اما بهینه نبودند. تفسیر نتایج این آزمایش هدف این نوشته نیست و می‌توانید اینجا بیشتر بخوانید:

https://en.wikipedia.org/wiki/Candle_problem

اما بد نیست بدانید که بعد از دانکر، دانشمندان دیگری با اهدافی متفاوت، این آزمایش را تکرار کردند. یکی از آن دانشمندان «توری هیگینز» (Edward Tory Higgins) – دانشمند، پژوهشگر، نظریه پرداز در زمینه روان‌شناسی اجتماعی، شخصیت و رشد - بود. هیگینز و همکارانش پی بردند که شیوه «جمله‌بندی در بیان مساله» منجر به تغییر چشمگیر تعداد افرادی شود که راه‌حل بهینه را می‌یابند! تاییدی بر اینکه تغییر در «بیان» می‌تواند بر شیوه فکر کردن ما و فهم ما تاثیرگذار باشد. گویی که فکر ما در سیطره‌ی ساختار و محدودیت‌های زبانی است که با آن حرف می‌زنیم. اما چطور؟

یک «اسکلت متحرک» بسازید!

اسکلت انسان (یا هر جنبنده‌ی دیگری)‌ را تصور کنید که می‌تواند اندامش را تکان دهد و این طرف و آن طرف برود. این تصویر را به خاطر بسپارید و هر وقت که در دوراهی (گاهی هم چندراهی) تصمیم‌گیری برای طراحی و پیاده‌سازی معماری یک سیستم قرار گرفتید، چشمان‌تان را ببندید، آن را به یاد آورید و فقط سعی کنید یک «اسکلت متحرک» بسازید.

استعاره «اسکلت متحرک» از آنِ «الیستر کوکبرن» (Alistair Cockburn) است. اشاره به سیستمی حداقلی، که اجزای اصلی آن کنار هم قرار گرفته‌اند و با هم چفت و بست شده‌اند. سیستمی که می‌توان به صورت سرتاسری (End-to-End) تستش کرد و ارتباط اجزای آن را بررسی نمود و به این ترتیب مطمئن شد که معماری در کل، معماری مناسبی است و کار می‌کند!

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

فرض کنید که آن اسکلت، پاهای کافی برای راه رفتن ندارد. بهتر است هر چه زودتر بفهمیم این اسکلت، بر خلاف تصور اولیه ما، کت‌واک (Catwalk) که هیچ، راه رفتن عادی هم نمی‌تواند!

«اسکلت متحرک» به عنوان یک راهبرد مفید در طراحی، پیاده‌سازی، تست و تکامل معماری سیستم‌، با رویکرد توسعه تدریجی محصول (Iterative & Incremental) که در متدهای چابک مورد تاکید قرار گرفته، سازگاری کاملی دارد. این راهبرد شاید در مورد سیستم‌های کوچک که تغییر در آنها کم هزینه‌تر است، چندان کاربردی نباشد، اما در مورد سیستم‌های بزرگ که توسعه آنها به همکاری بیش از یک تیم نیازمند است، می‌تواند به واسطه حلقه بازخورد سریعی که ایجاد می‌کند، از هدر رفت منابع جلوگیری کند و نگذارد مادامی که اسکلت لنگ می‌زند کسی به چشم و ابروی آن فکر کند.

جمع‌بندی:
«اسکلت متحرک» زشت و هولناک است و تا زمانی که تبدیل به «سوفیا لورن» شود راه درازی در پیش است. اما راه همین است. اسکلتی زشت و هولناک، که راه می‌رود.

—الیستر کوکبرن،‌ دانشمند علوم رایانه، از امضا کنندگان بیانیه چابک، مبدع مجموعه متدهای توسعه نرم‌افزار موسوم به کریستال (Crystal)، و نیز مبدع معماری شش ضلعی (Hexagonal Architecture) است.—

-روح‌الله دلپاک
@Break_Point

مروری بر اصل پیتر (Peter Principal) و تاثیر آن بر عملکرد تیم‌های توسعه نرم‌افزار

ناهید توسعه‌دهنده توانمندی است و در مدت حضورش در تیم، چالش‌های زیادی را در حوزه طراحی و توسعه محصول، با راهکارهای خلاقانه و سخت‌کوشی فراوان، حل کرده و به این ترتیب شایستگی خود را به عنوان یک توسعه‌دهنده‌ی ماهر، به اثبات رسانده است. مدتی بعد Team Leader  تیم‌شان از شرکت می‌رود. مدیران با توجه به عملکرد رضایت بخش ناهید تصمیم می‌گیرند که او را به عنوان Team Leader جدید معرفی کنند.

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

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

به این ترتیب کارکنان در سازمان‌ها تا حدی پیشرفت می‌کنند که دیگر کفایت ایفای نقش در سطحی بالاتر را نداشته باشند. دکتر لارنس پیتر، اصل پیتر را در کتابی به همین نام مطرح می‌کند و تاکید می‌کند که موقعیت‌های شغلی در سلسله مراتب سازمانی در نهایت توسط کارمندانی پر می‌شود که برای ایفای وظایف مرتبط با آن موقعیت ناکارآمد هستند.

برگردیم به داستان ناهید! ناهید که از ارتقا شغلی خودش، بسیار راضی به نظر می‌رسد خیلی زود متوجه می‌شود که برای نقش رهبری تیم، به مهارت‌هایی نیاز دارد که فاقد آنهاست. او از شیوه‌های بهبود بهره‌وری کار تیمی، تولید ناب، متدهای چابک و مربی‌گری افراد و تیم‌ها و ... اطلاعات کمی دارد. مشکل همین جا است! مدیری که ناهید را برای رهبری تیم برگزیده، عملکرد قبلی او در جایگاه توسعه‌دهنده نرم‌افزار را معیار ارزیابی قرار داده و درباره شایستگی‌های لازم برای کسب موقعیت شغلی جدیدش، سخت‌گیری‌ نکرده است.

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

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

سازمان‌های Developer Friendly چه جور سازمان‌هایی هستند؟

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

 

گمانم این است که کاربر پسند (User Friendly) بودن نرم‌افزارهایی که تولید می‌کنیم وقتی به کمال می‌رسد که خالقان آن تجربه کاربری، خودشان در سازمانی فعالیت کنند که Developer Friendly باشد. در اینجا منظورم از کاربر پسند بودن، صرفا شکل و شمایل و راحتی کار با محصول نیست. بلکه منظور رضایت بخش بودن تجربه‌ای است که کاربر از کار با محصول عایدش می‌شود. منظور از توسعه‌دهندگان هم فقط برنامه‌نویسان نیست. بلکه همه دست‌اندرکارانی است که برای خلق محصول و زنده نگه‌داشتن آن تلاش می‌کنند.

 

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

 

اما سازمان Developer Friendly چگونه سازمانی است؟ به نظرم همه آنچه که می‌توان در توصیف چنین سازمانی نوشت، به ظرافت و درستی تمام، در بیانیه چابک توسعه نرم‌افزار آورده شده است. چنین سازمانی، ارزش‌های بنیادی این بیانیه را می‌شناسد، پاس می‌دارد و آنها را زندگی می‌کند و می‌توان به وضوح دید که اصول دوازدگانه آن بیانیه چطور در سازمان رعایت می‌شود.

ده دستاورد مهم تست‌خودکار که کمتر مورد توجه هستند.

توسعه‌دهندگان، مدیران و ذینفعان محصول، اغلب به یک کارکرد تست خودکار یعنی «یافتن باگ» بیشتر از سایر دستاوردهای آن توجه می‌کنند. هرچند که «یافتن باگ» مهم است اما وقتی که تنها این کارکرد تست در نظر ما پررنگ شود و از دیگر مزایای تست‌خودکار غافل شویم، دیگر بعید نیست که از خیر همین تک کاربرد «یافتن باگ» بگذریم و این کار را بسپاریم به دو سه نفر که بنشینند و صبر پیش گیرند و دست به کار تست دستی شوند! خب هدف یافتن باگ است، اینها هم همین کار را می‌کنند؛ نه؟!

اما خودکارسازی تست، دستاوردهایی فراتر از «یافتن باگ» دارد. دستاوردهایی که اگر محقق شوند، همگی پی خواهیم برد که کارکرد «یافتن باگ»، تنها بخشی کوچک از اتمسفر مثبتی است که تست‌خودکار، در تیم/سازمان ایجاد می‌کند. اینجا به صورت خلاصه و فهرست‌وار به برخی از مهمترین‌ دستاوردهای تست‌خودکار اشاره کرده‌ام:

• تعادل کار و زندگی

کلنجار رفتن با سیستم‌هایی که کدهای کثیف و پر باگ دارند می‌تواند توسعه‌دهندگان را زمین‌گیر کند و آنها را تا دیروقت سر کار نگه دارد. چه کسی از داشتن نیروهای خسته و فرسوده که تعادل کار و زندگی‌شان به هم خورده منتفع می‌شود؟ این یک بازی باخت – باخت برای نیرو و سازمان است.

• یادگیری

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

• جلوگیری از کدورت‌ها

شاید شما هم چنین اعتراضی کرده‌ باشید که: «فلانی فیچر تولید کردی یا باگ؟ این چه وضعشه؟» شاید هم مورد خطاب چنین اعتراضی بوده‌اید! به هر حال این ادبیات می‌تواند به ایجاد کدورت و تضعیف روحیه کار تیمی منجر شود. تست‌خودکار که وجود داشته باشد، کمتر پیش می‌آید که چنین چیزی بگویید یا بشنوید!

• شجاعت تغییر

بدون تست‌خودکار، تغییر کابوس است. داشتن یک مجموعه تست‌خودکار قابل اعتماد، مانند سپری فولادی ما در برابر ضربه‌های ناشی از تغییر ایمن می‌کند.

• اعتماد

«بچه‌ها کسی اجازه نداره با Master مرج کنه! قبلش من باید همه کدها رو ریویو کنم!» این یک روش ناکارآمد در تیم‌هایی است که می‌خواهند فقدان تست‌خودکار را با کدریویوی فردی جبران کنند. قانونی که حامل پیام بی‌اعتمادی است. در تیمی که تست‌های خودکار به خوبی نوشته شده‌اند، نظارت بر صحت و کیفیت کد به ابزارها سپرده می‌شود و روابط آدمها با هم در تیرگی ناشی از چنین رفتارهای کنترلی، فرو نمی‌رود.

• حس افتخار

چه کسی دوست دارد عضو تیمی باشد که به دلیل وجود باگ‌‌های بازدارنده، مدام مورد نگاه سرزنش‌گرانه دیگران است؟ به بودن در چنین تیمی می‌شود افتخار کرد؟ به بودن در تیمی که محصول کم نقصی عرضه می‌کند چطور؟

• تست به عنوان مستند

تست‌ خوب، می‌تواند جایگزین بهتری برای مستندات مکتوب باشد. اعضای جدید تیم می‌توانند با مرور سناریوهای تست، بسیار سریعتر از خواندن مستندات یک PDF، بر منطق برنامه، معماری و کامپوننت‌ها مسلط شوند.

• ضرب‌آهنگ پایدار

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

• تخمین درست‌تر زمان فعالیت‌ها

«دو روزه ردیفش می‌کنیم!» اما در بعد از ظهر روز دوم، کار گره خورده و کلی درگیر خواندن کدهای قبلی و رفع‌باگ‌های کهنه شده‌ایم و بعید است که ۲ روز دیگر هم کار را تمام کنیم. تست‌خودکار می‌تواند باعث شود که از اثرات ناخواسته‌ی تغییرات کد مطلع شویم و مطمن شویم که تغییرات ما جایی را خراب نکرده است.

• صرفه‌جویی در هزینه‌های تولید

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

مجمع الجزایر تحلیل، توسعه، تست!

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

 

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

 

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

 

طبیعی است که اگر خودمان هم در یکی از این جزایر قرار بگیریم، بیشتر از هر چیز به فکر حفظ جزیره خودمان باشیم و چیزی را ارزشمند‌تر بدانیم که به نفع جزیره ماست و اگر هم مشکلی وجود داشته باشد، چه چیز راحتتر از اینکه تقصیر را گردن این یا آن جزیره بیندازیم؟!

 

اگر هوای یک جزیره طوفانی شود از آسمان سیل ببارد و به شرایط طاقت‌فرسایی گرفتار شوند، کسی از جزایر بغلی، محلی به آنها نخواهد گذاشت و اینطور نیست که به قول سعدی «دگر عضوها را نماند قرار»!

 

اما این جزایر همیشه هم بر سر جنگ نیستند و سیاست هم گاهی به کار خواهد آمد! برخی از ساکنین زیرک‌تر این جزایر، روابط و بده بستان‌هایی را با ساکنین جزایر بغلی شروع می‌کنند که الزاما به سود محصول مشترکشان نیست و بلکه مخرب است. گل بود و به سبزه نیز آراسته شد!

 

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

 

اما چطور می‌توان محصول مشترکی ساخت وقتی که ذهنمان درگیر جنگ سرد بین جزایر است و به این فکر می‌کنیم که پرچم جزیره خودمان را بالا نگه داریم؟

 

آیا بهتر نیست همه ما خودمان را ساکن یک جزیره بدانیم و به فکر بالا نگه داشتن یک پرچم باشیم؟ پرچم تیم!

 

- روح‌الله دلپاک

 

آیا «طراحی دامنه محور» ترجمه مناسبی برای Domain-Driven Design است؟

جستجوی عبارت «طراحی دامنه محور» در گوگل، بیش از ۲۰۰۰ نتیجه در بر دارد که می‌تواند نشانه‌ای از این باشد که عبارت «طراحی دامنه محور» به ترجمه‌ای متداول برای عبارت Domain-Driven Design تبدیل شده است. اما آیا چنین ترجمه‌ای، می‌تواند ایده اصلیِ رویکرد Domain-Driven Design را به مخاطب فارسی زبان بفهماند؟

 

هدف از این نوشته پیشنهاد یک ترجمه بهتر نیست (هر چند که از تلاش برای ارایه یک ترجمه بهتر استقبال می‌کنم) و صرفا به بررسی مناسب بودن عبارت «طراحی دامنه محور» برای ترجمه Domain-Driven Design بسنده می‌کنم.

 

از جمله موضوعاتی که در رویکرد DDD مورد تاکید فراوان قرار گرفته موضوع زبان فراگیر (Ubiquitous Language) است. منظور از زبان فراگیر، زبانی است که در هر نوع فعالیت مرتبط با توسعه محصول اعم از تحلیل، طراحی، پیاده‌سازی، تست و حتی مکاتبات رسمی و غیر رسمی مورد استفاده قرار می‌گیرد.

 

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

 

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

 

یافته‌های جدید ما از فضای مساله، مانند نیروی پنهانی هستند که به مدل وارد می‌شوند و مدل را بالغ‌تر می‌کنند و آن را به مدل مناسبتری برای حل مساله بدل می‌کنند.

اما منشا نیرویی که به کامل‌تر شدن مدل ما می‌انجامد چیست؟ منشاء این نیرو، حوزه مسایل کسب و کار یا به عبارت دیگر، همان Domain است. می‌توان گفت آنچه که طراحی ما را حالت می‌دهد (مانند خمیر بازی) و خوش فرم‌تر می‌کند، یافته‌های جدید و درک جدید ما از Domain است.

 

عبارت Domain-Driven Design هم بر همین موضوع دلالت دارد. سبکی از طراحی که کاملا تحت اثر نیرویی است که از Domain به آن وارد می‌شود و آن را وَرز می‌دهد. اگر در دامین مفهومی نو پدیدار شود یا مفهومی بسط پیدا کند و شفاف‌ شود، لاجرم باید آن تغییرات را در مدل منعکس کنیم.

 

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

 

اگر با این تعبیر از رویکرد #DDD موافق باشید، به نظر می‌رسد که عبارت «طراحی دامنه محور» ترجمه وفاداری به رویکرد DDD نیست. به این دلیل که اشاره‌ واضحی به این نکته‌ی مهم ندارد که طراحی «تحت تاثیر» نیرویی است که به دلیل تغییر و تحولات دامین به آن وارد می‌شود و آن را سر و شکل می‌دهد.

 

شاید مهمترین ضعف این ترجمه، انتخاب واژه «محور» به جای Driven- باشد که خب انتخاب دقیقی نیست. با رجوع به واژه‌نامه کمبریج می‌بینیم که در توضیح معنای -Driven (در شکل پسوندی)‌ گفته شده:

• Caused or influenced by something or someone.

- آنچه که تحت تاثیر چیزی یا کسی بوجود می‌آید و یا اتفاق می‌افتد.

 

لذا پسوند Driven- معنای «محور» یا «مرکز» ندارد و عبارت «طراحی دامنه محور» در ترجمه تحت الفظی نیز با اشکال همراه است.

 

جمع‌بندی:

عبارت «طراحی دامنه محور» به دو دلیل ترجمه مناسبی برای Domain-Driven Design نیست:

۱- ایده اصلی این رویکرد را به مخاطب منتقل نمی‌کند.

۲- در ترجمه تحت الفظی، «محور» ترجمه صحیحی از «-Driven» نیست.

 

چرا Continues بودن بعضی فعالیت‌ها در متدهای چابک مورد تاکید جدی قرار گرفته است؟

اصطلاحاتی مانند Continues Delivery, Continues Deployment, Continues Refactoring, Continues Exploration, Continues Integration مدتهاست که به نقل محافل توسعه‌دهندگان نرم‌افزار به خصوص آنهایی که برای چابک‌تر شدن تلاش می‌کنند، تبدیل شده است. اما منظور از Continues بودن کاری چیست و چرا اینقدر بر ویژگی Continues بودن چنین کارهایی تاکید می‌شود؟

 

برای انتخاب ترجمه مناسب واژه Continues با مشکل چندانی روبرو نیستیم. می‌توانید از بین این واژگان یکی را انتخاب کنید: پیوسته، مستمر، مداوم، بی‌وقفه، متوالی، همیشگی، پی در پی.
(در ادامه، از واژه «همیشگی» به جای Continues استفاده می‌کنم.)

 

اگر کاری ارزشمند است چرا آن را به صورت «همیشگی» انجام ندهیم؟ اگر کنکاش در نیازمندی مشتریان، بازسازی کدها (Code Refactoring)، یکپارچه‌سازی اجزای محصول و تحویل ارزش به دست مشتری کارهایی ارزشمندند، چرا آنها را به صورت همیشگی انجام ندهیم؟ 

 

نکته مهم اینست وقتی می‌توانیم کاری را به صورت «همیشگی» انجام دهیم که برای آن کار تمرین کرده باشیم، در آن چیره ‌دست شده باشیم و بتوانیم آن را به «راحتی» انجام دهیم. اگر می‌خواهیم کاری را همیشگی کنیم، باید آن را آسان کنیم. کاری را که سخت و پر دردسر باشد، نمی‌توان به صورت «همیشگی» انجام داد. در واقع تاکید بر انجام همیشگی چنین کارهایی به این دلیل است که تیم‌ها بتوانند به چنان مهارتی در انجام آن کار برسند که آن کار برای آنها به روالی عادی و عادت مرسوم تبدیل شود. 

 

از سوی دیگر، انجام «همیشگی» یک کار منجر به این می‌شود که برای آن کار یک «جریان» (Flow) ایجاد شود. وقتی کاری به صورت یک «جریان» در می‌آید، نشانه این است که موانعی که سر راه آن کار وجود داشته‌اند به مرور حذف شده‌اند. این همان وضعیتی است که تیم‌های چابک برای رسیدن به آن تلاش می‌کنند؛ یعنی برداشتن موانع بر سر راه خلق ارزش برای مشتری.

 

اما ایجاد «جریان» مزیت دیگری هم دارد. این مزیت را با ذکر مثالی بیان می‌کنم: 

روستایی را در نظر بگیرید که در نزدیکی آن رودخانه‌ای وجود دارد که در همه فصول سال آبی آرام در آن جریان دارد. این رودخانه حتی در تابستان هم خشک نمی‌شود و در زمستان هم از سیلاب‌های ویرانگر خبری نیست و کشاورزان بر اساس همین دانسته‌ها و اطمینان از اینکه جریان آب پایدار و همیشگی است به توسعه کشاورزی خود می‌پردازند. 

 

اما در جغرافیای دیگری، روستایی وجود دارد که در کنار آن رودخانه‌ای فصلی وجود دارد. گاهی پر آب است و گاهی خشک خشک! ممکن است تابستان یک سال آب داشته باشد و سال‌های بعد خشک باشد. در زمستان هم جریان آب ثابت نیست و گاهی سیلاب‌های ویرانگری را برای روستاییان به همراه می‌آورد. حتی بعضی روستاییان ممکن است به خیال اینکه در این رودخانه دیگر آبی جاری نخواهد شد، برای همیشه از آن روستا بروند.

 

شما دوست دارید ساکن کدام روستا باشید؟ مشتریان شما هم همین را دوست دارند. اگر بتوانید «جریان» تحویل ارزش به مشتری را مانند جریان آب آرام یک رودخانه برای مشتری فراهم کنید، آنها بهتر می‌توانند به توسعه کسب و کار خود بپردازند. مشتریان و ذینفعان خود را با این جریان همیشگی وفق خواهند داد و به شما اعتماد می‌کنند و دیگر از بابت نسخه جدید محصول (Big-Bang Release) که ممکن است برای آنها حکم همان سیل را داشته باشد، حیران و سرگردان نخواهند شد. 

جمع‌بندی:
تاکید بر ویژگی انجام دادن کارهای ارزشمند به صورت «همیشگی» باعث می‌شود تا تیم به تکاپوی انجام راحت‌تر آن کار بیفتد و از این راه در انجام آن کار به چیره‌دستی و تبحر برسد. همچنین انجام یک کار ارزشمند به صورت «همیشگی» باعث ایجاد جریان پایدار برای آن کار می‌شود. جریانی که می‌توان به آن اعتماد کرد و از احتمال وقوع اتفاقات غیر قابل پیش‌بینی (نظیر آن سیلاب) کاست.

آیا شما هم در موقعیت سیزیفیک قرار گرفته‌اید؟

«سیزیف نام قهرمانی در اساطیر یونان است. او به مجازاتی بی‌حاصل و بی‌پایان محکوم شد که در آن می‌بایست سنگ بزرگی را تا نزدیک قله‌ای ببرد و قبل از رسیدن به پایان مسیر، شاهد بازغلتیدن آن به اول مسیر باشد؛ و این چرخه تا ابد برای او ادامه داشت. به همین دلیل، انجام وظایفی که در عین دشواری، بی‌معنی و تمام نشدنی نیز هستند را گاهی «سیزیف‌وار» خطاب می‌کنند.» (ویکی‌پدیا)

 

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

 

اما نکته اینجا بود که مدیر آن واحد از تغییر برنامه انتشار زودتر از دیگران باخبر می‌شد ولی تغییر برنامه را به تیم اطلاع نمی‌داد و تصور می‌کرد که با این کار، سطح آمادگی، همدلی و توان مواجهه با شرایط سخت را در تیم بالا نگه می‌دارد و تیم اصطلاحاً «آبدیده» می‌شود.

 

مسلماً قرار گرفتن در موقعیت سیزیفیک، نه تنها تیم را به هیچ‌کدام از دستاوردهایی که آن مدیر تصور می‌کرد نرسانده بود، بلکه باعث شده بود تا انگیزه و اعتماد اعضای تیم از بین برود و رابطه‌ی تیم و آن مدیر، سرد و تیره شود.

 

برای تیم و به طور عام‌ برای همه انسان‌ها مهم است که مطمئن شوند که در پس رنج و زحمتی که متحمل می‌شوند، «معنا» و هدفی بزرگتر وجود دارد. بی‌معنا و نابود کردن دست‌رنج افراد (حتی در حالت خفیف)، و قرار دادن آنها در شرایط سیزیفیک، انگیزه‌های فردی-تیمی را چنان از ریشه می‌خشکاند که کمتر عامل انگیزشی می‌تواند باعث شود تا تیم دوباره به وضعیت قبلی برگردد و آن کار را با شور و شوق انجام دهد.

- روح‌الله دلپاک

مطالعه بیشتر: Work and Meaning

 

وقتی یک قصاب به ما درس ریفکتور می‌دهد!

تصور کنید وارد مغازه قصابی شده‌اید و به آقای قصاب سفارش یک شقه ران گوسفندی داده‌اید! حالا به ابتدای جمله برگردید! بله عرض کردم که «تصور» کنید!

 

جناب قصاب تند و تیز شروع به بریدن و تکه کردن گوشت می‌کند. شما هم منتظر ایستاده‌اید و در این خیال که به زودی چه خورشت و آبگوشت‌های لذیذی خواهید خورد، فرو رفته‌اید.

 

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

 

قصاب داستان ما، به دلیل اینکه همیشه حواسش به تیز بودن چاقویش بوده و آن را مرتب تیز کرده است، دیگر نیازی ندارد که برای تیز کردن چاقویش وقت زیادی صرف کند. سه چهار بار که چاقو را به سوهان بکشد، تیز می‌شود. کاری که چند ثانیه بیشتر وقت نمی‌گیرد!

 

اگر این کار را به صورت مرتب انجام ندهد، آن‌وقت به مشتری چهارم و پنجم نرسیده، «مجبور» می‌شود که مشتری را «معطل» کند تا چاقوی جدیدی تهیه کند و یا با چاقوی کند و کهنه شده، با زور و تقلا کارش را پیش ببرد.

 

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

 

ریفکتور (Refactor)، بخوانید تیز کردن چاقو باید جزیی از فعالیت‌های روزانه‌ی ما باشد. جوری که هیچ‌وقت نخواهیم که برای تیز کردن چاقوی توسعه، از مشتری فرصت بگیریم و وقتش را تلف کنیم. پس مثل آقای قصاب ریفکتور کنیم، هر روز، روزی چند بار. 

 

راستی آبگوشت‌تان نوش جان!