مقالات تجربه کاربری - طراحی پیمانهای افزایشی
طراحی پیمانهای افزایشی
طراحی پیمانهای افزایشی 
طراحی پیمانهای افزایشی (Incremental Modular Design) چیست؟
💡 این متن «بازنویسی آزاد» است: ایدهها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثالهای تازه بازگو شدهاند و ترجمهٔ کلمهبهکلمه نیست. بخشهای افزودهٔ مترجم در جعبهٔ منبع مشخص شدهاند.
پروژهٔ بزرگی که به قطعههای کوچک تقسیم نشود، فقط یک راه شکست دارد: کامل.
تعریف
طراحی پیمانهای افزایشی، پروژههای بزرگمقیاس را به پیمانههای کوچک و مستقل میشکند.
و فایدهاش این است: «نگهداری و مقیاسپذیری آسانتر میشود، چون هر پیمانه پیش از یکپارچهسازی، جداگانه ساخته و آزموده میشود.»
و دو کلمهٔ نام این رویکرد، دو ایدهٔ متفاوتاند که اغلب با هم اشتباه گرفته میشوند.
«پیمانهای» دربارهٔ ساختار است — سامانه از چه اجزایی ساخته شده. و «افزایشی» دربارهٔ زمان است — به چه ترتیبی ساخته میشود.
و میشود یکی را بدون دیگری داشت. سامانهٔ پیمانهای که یکجا تحویل داده شود، و پروژهٔ افزایشی که هر مرحلهاش کل سامانه را دست بزند.
و ارزش واقعی وقتی آزاد میشود که هر دو با هم باشند.
چهار اصل
یک: تعریف هدفها. همراستاکردن تأمینکنندگان مالی، جامعهها و ذینفعان روی هدفهای پروژه.
دو: مردمیکردن طراحی. درگیرکردن کاربر نهایی از راه روشهای طراحی مشارکتی، برای شناسایی مسئله و همآفرینی راهحل.
سه: کمینهٔ پروژهٔ ماندگار. تحویل راهحل بهصورت افزایشی، تحلیل نتیجه، و تنظیم مسیر بر پایهٔ یافتهها.
چهار: پیمانههای مستقل. ساختن پیمانههایی با ورودی و خروجی روشن، در حالی که کارکرد درونیشان انعطافپذیر میماند.
و اصل چهارم، فنیترین و مهمترینشان است. قرارداد بیرونی سفت، درون نرم.
و همین یک قاعده است که همهٔ فایدههای بعدی از آن میآید. اگر ورودی و خروجی پیمانه ثابت نباشد، جایگزینکردنش ممکن نیست.
چطور کار میکند
و این رویکرد سه چیز را ترکیب میکند: توسعهٔ چابک · برنامهنویسی شیءگرا · و اصول افزایشگرایی.
و تیم پیمانهها را پشت سر هم میسازد — تشبیه منبع این است: «مثل چیدن آجرهای پیِ یک خانه.»
و پیش از رفتن به مرحلهٔ بعد، عملکرد را ارزیابی میکند.
و شرط هر پیمانه این است: باید نتیجهای آزمونپذیر و مفید تولید کند که مرحلههای بعد را آگاه کند.
و کلمهٔ «مفید» در این جمله همان چیزی است که این رویکرد را از تقسیمکار ساده جدا میکند.
یعنی پیمانهای که فقط بعد از کاملشدن بقیه ارزش دارد، پیمانه نیست — یک تکه از کار نیمهتمام است.
سه شکل انعطاف
انعطاف در نیازمندیها. تیم مسیرش را بر پایهٔ یادگیری تکرارشونده تنظیم میکند.
انعطاف در جایگزینی پیمانه. میشود یک پیمانه را بهروز کرد بدون آنکه کل سامانه به هم بریزد.
انعطاف در انطباق محلی. میشود کارکرد درونی را برای بافتهای فرهنگی سفارشی کرد، در حالی که واسطها استاندارد میمانند.
و مورد سوم کمگفتهترین فایدهٔ این رویکرد است، و برای ما مهمترین. در بخش پایانی به آن برمیگردم.
فایدههای دیگر
- - چرخهٔ کوتاهتر پروژه که یادگیری سریعتر از خطا را ممکن میکند.
- - ریسک کمتر از راه اعتبارسنجی در مقیاس کوچک، پیش از بزرگشدن.
- - نگهداری آسانتر و همکاری روانتر تیم چندتخصصی.
- - و تجربهٔ یکدست کاربر از راه مؤلفههای قابل استفادهٔ دوباره.
و فایدهٔ دوم — ریسک کمتر — همان چیزی است که تأمین مالی را ممکن میکند. سرمایهگذار به مرحلهای که نتیجهاش دیده میشود راحتتر پول میدهد تا به یک وعدهٔ سهساله.
کاربردها
پروژههای غیردیجیتال. زیرساخت، شبکهٔ برق و سامانههای حملونقل از پیادهسازی مرحلهای پیمانهها و ارزیابی میان مرحلهها سود میبرند.
محصولهای دیجیتال. سامانههای طراحی از مؤلفههای پیمانهای — دکمه، فرم، ناوبری — برای یکدستی و تکرار سریع در سکوهای مختلف استفاده میکنند.
و این دو نمونه به نظر بیربط میآیند، اما یک چیز مشترک دارند: در هر دو، هزینهٔ اشتباهِ کشفنشده با گذشت زمان چند برابر میشود.
پنج بهترینروش
- - سامانهٔ طراحی یکپارچه با استانداردهای ثابت برای فاصلهگذاری، تایپوگرافی و رفتار بسازید.
- - ورودی و خروجی پیمانه را پیشبینیپذیر نگه دارید تا یکپارچهسازی روان باشد.
- - همکاری نزدیک طراح و توسعهدهنده را با مستندسازی و کنترل نسخه حفظ کنید.
- - پیمانهها را در بافتهای مختلف آزمون کنید تا ناسازگاریها زود پیدا شوند.
- - و دسترسپذیری و فراگیری فرهنگی را در سطح مؤلفه اعمال کنید تا کل سامانه سود ببرد.
و مورد آخر بیشترین بازده را دارد. یک بار درستکردن کنتراست در مؤلفهٔ دکمه، همهٔ دکمههای محصول را درست میکند.
و عکسش هم صادق است، که کمتر گفته میشود: یک خطا در سطح مؤلفه هم در همهجا تکثیر میشود.
هزینهٔ پیمانهایبودن
این بخش افزودهٔ من است، چون منبع فقط فایدهها را میشمارد و این رویکرد هزینههای واقعی دارد.
یک: هزینهٔ اولیه بالاتر است. تعریف قرارداد میان پیمانهها، وقت میبرد — وقتی که در پروژهٔ یکپارچه صرف ساختن میشد.
و نتیجهاش این است که در پروژههای کوچک، پیمانهایکردن اغلب ضرر است.
دو: مرزها اشتباه در میآیند. شکستن یک سامانه به پیمانه یعنی حدسزدن اینکه کدام بخشها مستقل از هم تغییر میکنند.
و اگر این حدس اشتباه باشد، هر تغییری به چند پیمانه دست میزند — و آنوقت همهٔ هزینه را دادهاید بدون هیچ فایدهای.
سه: یکدستی میتواند به یکنواختی برسد. مؤلفهٔ قابل استفادهٔ دوباره، طراح را به بازاستفاده تشویق میکند، حتی جایی که مسئله چیز دیگری میخواهد.
و علامتش این است: وقتی جواب همهٔ مسئلهها «یک کارت دیگر اضافه کنیم» شد، سامانهٔ طراحی از ابزار به قفس تبدیل شده.
و هیچکدام اینها دلیل نکردنش نیست. فقط یعنی پیمانهایبودن یک تصمیم است با شرایط، نه یک فضیلت همیشگی.
مرز پیمانه را کجا بکشیم
و ریسک دوم بالا — اشتباهدرآمدن مرزها — پرسشی میسازد که منبع پاسخش را نمیدهد: مرز پیمانه را بر چه اساسی بکشیم؟
و پاسخ رایج و اشتباه، تقسیم بر اساس نوع کار است: یک پیمانه برای رابط، یکی برای داده، یکی برای منطق.
و مشکلش این است که هر تغییر واقعی، هر سه را دست میزند. افزودن یک میدان تازه یعنی هم رابط، هم داده، هم منطق.
و پاسخ بهتر، تقسیم بر اساس چیزی است که با هم عوض میشود. اگر دو بخش همیشه همزمان تغییر میکنند، یک پیمانهاند.
و آزمون عملیاش این است: پنج تغییر آخری را که واقعاً انجام دادهاید بنویسید، و ببینید هر کدام چند پیمانه را دست زده.
و اگر بیشترشان فقط یکی را دست زدهاند، مرزها درستاند. و اگر بیشترشان سهتا را، مرزها بر اساس نوع کار کشیده شدهاند نه بر اساس تغییر.
مدافع سرشناس
و دان نورمن — که «پدرخواندهٔ طراحی تجربهٔ کاربری» خوانده میشود — از این رویکرد بهعنوان چارچوبی برای پرداختن پایدار به چالشهای جهانی دفاع میکند.
و دلیل دومش عملیتر است: جلب تأمین مالی ذینفعان برای پروژههای پیچیده.
و همانطور که در طراحی بشریتمحور نوشتم، این بخشی از استدلال بزرگتر اوست دربارهٔ مسئلههایی که در مقیاس جامعهاند.
در بافت فارسی
یک: «انطباق محلی با واسط استاندارد» اینجا مهمترین بند است. این دقیقاً الگویی است که یک محصول جهانی را قابل استفاده در ایران میکند.
و شکل عملیاش این است: تقویم، اعداد، جهت متن و قالب تاریخ را پیمانهای کنید — نه اینکه در سراسر کد پخششان کنید.
و اگر این کار را از اول بکنید، پشتیبانی از تقویم شمسی یک پیمانه است. و اگر نکنید، یک بازنویسی است.
دو: بودجهٔ مرحلهای با واقعیت اقتصادی اینجا سازگارتر است. در محیطی که برنامهریزی بلندمدت سخت است، پروژهٔ سهساله عملاً قابل تعهد نیست.
و «کمینهٔ پروژهٔ ماندگار» راهی است برای ساختن چیزی که اگر بودجه قطع شد، همان تکهای که ساخته شده هم کار کند.
سه: جابهجایی نیرو، مستندسازی را ضروری میکند. پیمانهایبودن وقتی جواب میدهد که قرارداد میان پیمانهها نوشته شده باشد.
و در تیمی که هر سال ترکیبش عوض میشود، قراردادِ نانوشته یعنی هیچ قراردادی.
چهار: سامانهٔ طراحی فارسی، از صفر ساخته نمیشود. بهتر است یک سامانهٔ موجود را بردارید و لایهٔ راستبهچپ و تایپوگرافی فارسی را بهعنوان پیمانه رویش بگذارید.
و همان اصل چهارم است که این را ممکن میکند: واسط ثابت میماند و درون عوض میشود.
جمعبندی
- - طراحی پیمانهای افزایشی، پروژهٔ بزرگ را به پیمانههای کوچک و مستقل میشکند که جداگانه ساخته و آزموده میشوند
- - «پیمانهای» دربارهٔ ساختار است و «افزایشی» دربارهٔ زمان — و ارزش واقعی وقتی آزاد میشود که هر دو با هم باشند
- - چهار اصل: تعریف هدفها · مردمیکردن طراحی · کمینهٔ پروژهٔ ماندگار · و پیمانههای مستقل
- - و اصل چهارم هستهٔ کار است: قرارداد بیرونی سفت، درون نرم
- - ترکیبی از توسعهٔ چابک، برنامهنویسی شیءگرا و افزایشگرایی — مثل چیدن آجرهای پیِ یک خانه
- - هر پیمانه باید نتیجهٔ آزمونپذیر و مفید بدهد — وگرنه پیمانه نیست، یک تکه از کار نیمهتمام است
- - سه شکل انعطاف: در نیازمندیها · در جایگزینی پیمانه · و در انطباق محلی با حفظ واسط استاندارد
- - فایدهها: چرخهٔ کوتاهتر · ریسک کمتر · نگهداری آسانتر · و تجربهٔ یکدست
- - پنج بهترینروش — و اعمال دسترسپذیری در سطح مؤلفه بیشترین بازده را دارد، همانطور که خطا در آن سطح بیشترین تکثیر را
- - هزینههایش: هزینهٔ اولیهٔ بالاتر · احتمال اشتباهدرآمدن مرزها · و رسیدن یکدستی به یکنواختی
- - مرز پیمانه را بر اساس «چیزی که با هم عوض میشود» بکشید، نه بر اساس نوع کار — و با پنج تغییر آخرتان بسنجیدش
- - دان نورمن مدافع آن است، هم برای چالشهای جهانی و هم برای جلب تأمین مالی
- - و در فارسی: بومیسازی را پیمانه کنید · بودجهٔ مرحلهای بسازید · قرارداد را بنویسید · و سامانهٔ طراحی را از صفر نسازید
منبع
این نوشته «بازنویسی آزاد» است از مطلب What is Incremental Modular Design? در وبسایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایه — تعریف طراحی پیمانهای افزایشی بهعنوان شکستن پروژههای بزرگمقیاس به پیمانههای کوچک و مستقل و نقلقول دربارهٔ آسانتر شدن نگهداری و مقیاسپذیری بهدلیل ساخت و آزمون جداگانهٔ هر پیمانه پیش از یکپارچهسازی؛ هر چهار اصل یعنی تعریف هدفها و همراستاکردن تأمینکنندگان مالی و جامعهها و ذینفعان، مردمیکردن طراحی از راه طراحی مشارکتی، کمینهٔ پروژهٔ ماندگار و تحویل افزایشی و تحلیل و تنظیم، و پیمانههای مستقل با ورودی و خروجی روشن و کارکرد درونی انعطافپذیر؛ بخش چطور کار میکند شامل ترکیب توسعهٔ چابک و برنامهنویسی شیءگرا و اصول افزایشگرایی و ساخت پشتسرهم پیمانهها و تشبیه چیدن آجرهای پیِ خانه و ارزیابی عملکرد پیش از مرحلهٔ بعد و شرط تولید نتیجهٔ آزمونپذیر و مفید؛ سه شکل انعطاف در نیازمندیها و جایگزینی پیمانه و انطباق محلی با حفظ واسط استاندارد؛ فایدههای دیگر شامل چرخهٔ کوتاهتر و ریسک کمتر و نگهداری آسانتر و همکاری تیم چندتخصصی و تجربهٔ یکدست از راه مؤلفهٔ قابل استفادهٔ دوباره؛ کاربردها در پروژههای غیردیجیتال مثل زیرساخت و شبکهٔ برق و حملونقل و در محصولهای دیجیتال و سامانههای طراحی؛ هر پنج بهترینروش؛ و معرفی دان نورمن بهعنوان پدرخواندهٔ طراحی تجربهٔ کاربری و مدافع این رویکرد برای چالشهای جهانی و جلب تأمین مالی — از این منبع گرفته شده. متن فارسی، ساختار بخشها و همهٔ تحلیلها کاملاً مستقل نوشته شدهاند.
متن مطلب اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمهبهکلمه ارائه نشده و متن کامل انگلیسی (بههمراه همهٔ منابع مرتبط) در لینک زیر در دسترس است.
بخشهای افزودهٔ مترجم: صورتبندی آغازین دربارهٔ تنها راه شکستِ پروژهٔ تقسیمنشده؛ تفکیک دو کلمهٔ نام رویکرد یعنی پیمانهای دربارهٔ ساختار و افزایشی دربارهٔ زمان، امکان داشتن یکی بدون دیگری، و گزارهٔ آزادشدن ارزش واقعی با همزمانی هر دو؛ صورتبندی اصل چهارم به «قرارداد بیرونی سفت، درون نرم» و تشخیص آن بهعنوان سرچشمهٔ همهٔ فایدهها؛ برجستهکردن کلمهٔ «مفید» بهعنوان مرز این رویکرد با تقسیمکار ساده و گزارهٔ اینکه پیمانهٔ بیارزش پیش از کاملشدن بقیه، پیمانه نیست؛ توضیح اینکه ریسک کمتر همان چیزی است که تأمین مالی را ممکن میکند؛ تشخیص وجه مشترک دو دستهٔ کاربرد یعنی چندبرابرشدن هزینهٔ اشتباه کشفنشده با گذشت زمان؛ برجستهکردن بازده بالای اعمال دسترسپذیری در سطح مؤلفه و تکثیر متقارن خطا در همان سطح؛ کل بخش «هزینهٔ پیمانهایبودن» شامل بالاتر بودن هزینهٔ اولیه و ضرربودنش در پروژهٔ کوچک، احتمال اشتباهدرآمدن مرزها و بیفایدهشدن کل هزینه، رسیدن یکدستی به یکنواختی و علامت تبدیلشدن سامانهٔ طراحی از ابزار به قفس، و جمعبندی اینکه پیمانهایبودن تصمیمی با شرایط است نه فضیلت همیشگی؛ کل بخش «مرز پیمانه را کجا بکشیم» شامل رد تقسیم بر اساس نوع کار و دلیلش، پیشنهاد تقسیم بر اساس چیزی که با هم عوض میشود، و آزمون عملی پنج تغییر آخر؛ و کل بخش بافت فارسی شامل مرکزیبودن انطباق محلی با واسط استاندارد و پیشنهاد پیمانهکردن تقویم و اعداد و جهت متن و قالب تاریخ، سازگاری بودجهٔ مرحلهای با واقعیت اقتصادی و بازتعریف کمینهٔ پروژهٔ ماندگار بهعنوان چیزی که با قطع بودجه هم کار کند، ضروریشدن مستندسازی قرارداد در تیم پرجابهجایی، و پیشنهاد ساختن لایهٔ راستبهچپ و تایپوگرافی فارسی بهعنوان پیمانه روی سامانهٔ موجود
تصاویر: هیچ تصویری از مطلب اصلی بازتولید نشده است. هر سه نمودار این صفحه طراحی مستقل مترجم است.
مشاهدهٔ مطلب اصلی
مترجم: سپنتا پویا
طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمیگردانم.
دربارهٔ من