اشکالاتی که مدل چابک (Agile) از نظر تجربه‌کاربر داره

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

معمولا توی مدل چابک ما کار رو به یک سری اسپرینت تقسیم می‌کنیم و هر کدوم از این اسپرینت‌ها روی یک سری از قابلیت و محتوا‌ها تمرکز داره.

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

همینطور این روش کار تست کاربردپذیری رو یه خورده فریبنده می‌کنه، چون هنوز شما هیچ MVP (کمینه محصول)ی در اختیار ندارید تا با اون تستش کنید. مثلا شما چطور می‌تونید وقتی همه محتواها به صورت کامل وجود ندارن معماری اطلاعات رو تست کنید؟

یه ویدئو خوب از خانوم Voychehovski هست با عنوان « The Simplicity Imperative » که ایشون توی صحبت‌هاشون یه راه حل ارائه کردن. خانوم Voychehovski پیشنهاد می‌کنه که ما به جای اینکه اسپرینت‌ها رو بر اساس قابلیت‌ها (Functionality) سازماندهی کنیم، بر اساس Fidelity (که من نمی‌دونم چی می‌شه ترجمش کرد) سازماندهی کنیم.

به عبارتی اسپرینت ۱ باید یه مدل کامل از همه قابلیت‌های MVP‌ باشه. اسپرینت ۲ باید یه وایرفریم با Fidelity بالا و اسپرینت ۳ هم نسخه نهایی.

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

البته این روشی نیست که خود من ازش استفاده کرده باشم، اما به نظر می‌رسه می‌تونه اون اشکالی که من از منظر طراحی به مدل چابک (Agile) وارد می‌دونم رو پوشش بده. شما چی فکر می‌کنید؟ آیا هیچ وقت از این روش استفاده کردید؟ من دوست دارم قبل از اینکه خودم برم سراغ این روش نظر شما رو هم بدونم.