منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

طراحی چابک (Agile Design) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

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

در عمل اما، بیشتر تیم‌ها با یک مسئلهٔ مشخص روبه‌رو می‌شوند که کمتر صریح گفته می‌شود: طراحی و توسعه ریتم یکسانی ندارند. این مقاله بیشتر دربارهٔ همین ناهم‌ریتمی است تا دربارهٔ تعریف‌ها.

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

طراحی چابک چیست؟

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

در عمل با چند چارچوب و ابزار پیاده می‌شود:

• - چارچوب‌ها: اسکرام (چرخه‌های زمان‌بندی‌شده و نقش‌های مشخص)، کانبان (مدیریت جریان کار بدون چرخهٔ ثابت)، و ترکیبشان.
• - ابزارها: داستان کاربر، اسپایک (کار پژوهشی زمان‌محدود برای رفع ابهام)، اپیک (قابلیت بزرگی که در چند چرخه پخش می‌شود)، جلسهٔ روزانه، و بازبینی و بازنگری پایان چرخه.

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

مسئلهٔ واقعی: دو ریتم متفاوت

این بخش افزودهٔ مترجم است. مشکلی که تقریباً هر تیمی تجربه می‌کند این است: توسعه برای شروع به قطعیت نیاز دارد و طراحی برای رسیدن به قطعیت به زمان.

اگر طراح را در همان چرخه‌ای بگذارید که توسعه‌دهنده در آن کد می‌نویسد، یکی از دو حالت رخ می‌دهد و هر دو بد است:

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

و یک حالت سوم که بدترین است و زیاد دیده می‌شود: طراحی به‌کلی از چرخه بیرون می‌ماند و به «کشیدن صفحه برای تیکتی که از قبل تعریف شده» تقلیل پیدا می‌کند. در این حالت، اسم فرایند چابک است اما آنچه واقعاً اتفاق می‌افتد آبشار است با اسپرینت‌های کوچک‌تر — و طراح در انتهای زنجیره نشسته، نه در ابتدای آن. این همان چیزی است که در بلوغ تجربهٔ کاربری نشانهٔ «طراحی به‌عنوان خدمت» نامیدیم.

راه‌حل متعارف: دو مسیر موازی

پاسخ رایج این است که به‌جای یک مسیر، دو مسیر موازی داشته باشید:

• - مسیر کشف: پژوهش، طرح‌های اولیه، نمونه‌سازی و آزمون. خروجی‌اش دانش است — یعنی چیزی که یاد گرفته‌ایم و تصمیمی که گرفته‌ایم.
• - مسیر تحویل: ساختن و انتشار. خروجی‌اش نرم‌افزار کارکننده است.

مسیر کشف معمولاً یک چرخه جلوتر حرکت می‌کند: آنچه این هفته آزموده می‌شود، هفتهٔ بعد ساخته می‌شود. منبع اصلی هم بی‌آنکه نامش را ببرد، همین را توصیه می‌کند.

دو نکتهٔ عملی که این الگو را نجات می‌دهند:

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

هزینهٔ غایب از فهرست‌ها: بدهی طراحی

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

سازوکارش دقیقاً مثل بدهی فنی است. هر چرخه یک قطعهٔ کوچک تحویل می‌دهد و هر قطعه، به‌تنهایی، قابل قبول است. اما چون هیچ‌کس در هیچ چرخه‌ای مسئول کل نیست، ناهماهنگی‌ها آرام‌آرام جمع می‌شوند:

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

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

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

• - یک سیستم طراحی حتی اگر کوچک باشد. لازم نیست کامل باشد؛ همین که رنگ و فاصله و دکمه در یک جا تعریف شده باشند، بیشتر این بدهی را از ابتدا حذف می‌کند.
• - یک بازبینی دوره‌ای «از فاصله». ماهی یک بار، صفحه‌های اصلی را کنار هم بگذارید و فقط دنبال ناهماهنگی بگردید — نه دنبال باگ.
• - ثبت بدهی به‌جای فراموشی‌اش. وقتی به‌خاطر فشار زمان راه‌حل موقتی می‌گذارید، همان‌جا در فهرست کارها ثبتش کنید. بدهیِ نوشته‌نشده، بدهیِ پرداخت‌نشده است.

اجایل‌فال: وقتی اسم می‌ماند و محتوا می‌رود

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

• - فاصلهٔ جلسه‌ها طولانی‌تر می‌شود و بازخورد دیرتر می‌رسد.
• - سیلوها برمی‌گردند: طراحی، توسعه و محصول دوباره جدا می‌نشینند و از راه سند با هم حرف می‌زنند.
• - مستندات سنگین می‌شوند و تصمیم‌گیری به تأیید سند وابسته می‌شود.
• - چرخه‌ها ثابت می‌مانند اما محتوایشان از پیش تعیین‌شده است — یعنی برنامهٔ شش‌ماهه را به دوازده اسپرینت تقسیم کرده‌اید و اسمش را چابک گذاشته‌اید.

آزمون تشخیصش هم یک پرسش است: آخرین باری که نتیجهٔ یک چرخه، برنامهٔ چرخهٔ بعد را عوض کرد کی بود؟ اگر یادتان نمی‌آید، چیزی که دارید تقویم است نه چابکی.

چابکی تشریفاتی در بازار ایران

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

چند شکل مشخصش:

• - جلسهٔ روزانه به گزارش‌دهی تبدیل می‌شود. به‌جای هماهنگی میان اعضا، هرکس به مدیر گزارش می‌دهد. تفاوتش را از جهت نگاه‌ها می‌شود فهمید.
• - بازنگری پایان چرخه برگزار نمی‌شود یا تشریفاتی است. و این مهم‌ترین جلسه است، چون تنها جایی است که خودِ فرایند می‌تواند عوض شود.
• - بی‌ثباتی بیرونی، افق را کوتاه می‌کند. وقتی قیمت‌ها و قواعد و اولویت‌ها مدام عوض می‌شوند، برنامهٔ سه‌ماهه بی‌معنا می‌شود. نکتهٔ ظریف این است که این وضعیت، چابکی را لازم‌تر می‌کند نه بی‌فایده‌تر — اما در عمل معمولاً به واکنشی‌بودن ختم می‌شود، که چابکی نیست.
• - «چابک» به‌معنای «سریع» فهمیده می‌شود. این پرتکرارترین بدفهمی است. چابکی دربارهٔ سرعت نیست؛ دربارهٔ کوتاه‌کردن فاصلهٔ میان تصمیم و بازخورد است. تیمی که سریع می‌سازد و هیچ‌وقت نمی‌سنجد، فقط دارد سریع‌تر حدس می‌زند.

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

جمع‌بندی

• - چابکی از بیانیهٔ ۲۰۰۱ آمد و اصل محوری‌اش پذیرفتن عدم قطعیت است: ساختاری بسازیم که یادگیری را ارزان کند.
• - مسئلهٔ واقعی طراحی چابک، ناهم‌ریتمی است: توسعه برای شروع به قطعیت نیاز دارد و طراحی برای رسیدن به قطعیت به زمان.
• - راه‌حل متعارف دو مسیر موازی است — کشف و تحویل — با فاصلهٔ حدود یک چرخه. دو مسیر یعنی دو نوع کار، نه دو تیم.
• - بدهی طراحی در فهرست دشواری‌ها غایب است: هر قطعه سر جای خود درست است و ناهماهنگی فقط از فاصله دیده می‌شود.
• - درمانش سیستم طراحی حتی کوچک، بازبینی دوره‌ای «از فاصله»، و ثبت بدهی به‌جای فراموشی‌اش است.
• - اجایل‌فال یعنی اسم ماندن و محتوا رفتن. آزمونش: آخرین بار کی نتیجهٔ یک چرخه برنامهٔ چرخهٔ بعد را عوض کرد؟
• - در بازار ایران، آیین‌ها پذیرفته شده‌اند و اختیار نه. و «چابک» با «سریع» اشتباه گرفته می‌شود — در حالی که چابکی دربارهٔ کوتاه‌کردن فاصلهٔ تصمیم و بازخورد است.