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

توسعهٔ چابک (Agile Development) چیست؟

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

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

تعریف

توسعهٔ چابک یک روش‌شناسی تکرارشوندهٔ توسعهٔ نرم‌افزار است. تیم‌های خودسازمان‌ده و میان‌وظیفه‌ای مرتباً شرایط و نیاز کاربر را تحلیل می‌کنند و پروژه را با آن تطبیق می‌دهند. تیم‌های اسکرام کیفیت را در اسپرینتها با تحویل‌های کوتاه‌مدت بهبود می‌دهند.

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

پیشینه: پادزهر انعطاف‌ناپذیری

در میانهٔ دههٔ ۱۹۹۰، بسیاری از حرفه‌ای‌های نرم‌افزار از فرایندهایی که آن‌ها را ریزمدیریت می‌کرد و نیازشان را نمی‌دید خسته شده بودند. روش‌های تکرارشونده از قبل وجود داشت، اما چیزی پویاتر لازم بود. پس رویکردی را ساده کردند که در آن می‌شد انعطاف‌پذیر ماند و به چالش‌های طراحی در لحظهٔ بروزشان پاسخ داد — و درست هم نامش را «چابک» گذاشتند.

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

• - افراد و تعامل‌ها بر فرایندها و ابزارها؛
• - نرم‌افزار کارکننده بر مستندسازی جامع؛
• - همکاری با مشتری بر مذاکرهٔ قراردادی؛
• - پاسخ‌دادن به تغییر بر پیروی از برنامه.

و نویسندگانش تأکید داشتند که شفافیت و تکرار ضروری‌اند و مشتری باید در سراسر پروژه درگیر بماند.

مسئلهٔ آبشار و پاسخ چابک

در آبشار، هر مرحله و اثرش مستقیم به مرحلهٔ بعد سرریز می‌شود؛ پس نگه‌داشتن تصویر کلی در نگاه روزانه سخت است، و اعضا در سیلوهایشان می‌مانند و تحویل‌ها را کورکورانه به تیم بعدی می‌دهند — عادتی که به آن «انداختن از روی دیوار» می‌گویند.

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

دو فرهنگ: چابکی و تجربهٔ کاربری

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

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

و جملهٔ کلیدی‌اش: «طراحی باید در پرداختن به مسائل درست در اسپرینت‌ها، پیش‌روِ توسعه باشد.»

«بر» با «به‌جای» یکی نیست

این بخش افزودهٔ مترجم است، و به‌نظرم پرهزینه‌ترین بدفهمی این حوزه است. هر چهار ارزش با کلمهٔ «بر» نوشته شده‌اند، و خودِ بیانیه در ادامه می‌گوید در قلم‌های سمت راست هم ارزش هست. یعنی آن جمله‌ها می‌گویند وقتی مجبور به انتخاب شدید کدام را فدا کنید — نه اینکه پیش‌فرض کدام را حذف کنید.

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

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

راه‌حلی که منبع در پرسش‌و‌پاسخ دفن کرده

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

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

صورت عملی‌اش این است:

• - طراحی روی اسپرینت N+1 کار می‌کند، توسعه روی N. یعنی وقتی توسعه کاری را برمی‌دارد، تصمیم‌هایش قبلاً گرفته شده‌اند.
• - پس‌انداز کار طراحی جداست. اگر در یک فهرست با کارهای توسعه باشد، همیشه پایین می‌رود.
• - و مهم‌ترین قید: خروجی اسپرینت طراحی باید یک تصمیم باشد، نه یک صفحه. «این جریان را با پیش‌فرض الف می‌سازیم چون در آزمون سه نفر از پنج نفر گیر کردند» یک تصمیم است؛ یک فایل فیگما نیست.

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

جلسهٔ روزانه‌ای که به گزارش تبدیل شده

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

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

و کاری که آن جلسه می‌تواند بکند و تخته نمی‌تواند، فقط دو چیز است:

• - آشکار‌کردن مانع‌ها. چیزی که یک نفر منتظرش است و نمی‌داند از چه کسی بخواهد.
• - و آشکار‌کردن اختلاف‌ها. دو نفر که فهم متفاوتی از یک کار دارند و هنوز نمی‌دانند. همان‌طور که در پژوهش کنشی نوشتم، اختلاف‌ها معمولاً یافتهٔ اصلی‌اند.

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

«اسپایک»، تنها جای مجاز پژوهش در این چارچوب

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

و به‌نظرم این مهم‌ترین قلم کم‌استفادهٔ کل چارچوب است. اسپایک تنها جایی است که این ساختار برای پژوهش در نظر گرفته — و دقیقاً به همین دلیل استفاده نمی‌شود: چیزی تولید نمی‌کند که در بازبینی پایان اسپرینت نمایش داده شود. سه قاعدهٔ عملی:

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

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

در بافت فارسی: آیین‌ها آمدند، شفافیت نه

این بخش هم افزودهٔ مترجم است و چهار نکته دارد.

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

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

سه: «تیم میان‌وظیفه‌ای» وقتی تیم یک نفر است. در بیشتر تیم‌های ما یک نفر همزمان طراح و پژوهشگر و نویسندهٔ متن است. آن‌وقت «میان‌وظیفه‌ای» به «یک نفر با چهار کار» فرو می‌ریزد و پژوهش، که مهلت بیرونی ندارد، همیشه حذف می‌شود. راه‌حل صادقانه‌اش پنهان‌کردن این وضع نیست؛ مرئی‌کردن نقش‌ها در زمان است: مثلاً دو صبح در هفته فقط پژوهش، در تقویم، مثل هر جلسهٔ دیگری. نقشی که در تقویم جا ندارد، وجود ندارد.

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

جمع‌بندی

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