در پروژه های چابک (Agile)، هدف به واحدهای جداگانه ای از کار که توصيف کننده يک ویژگی یا توانایی انجام یک عمل از دیدگاه کاربر نهایی است، شکسته میشود. اين واحدهای کاری را معمولا داستان کاربری (user story) می‌نامند.
اکنون يک سوال پيش می آيد: بهترين راه برای شکستن کارها به داستانهای کاربری چيست؟ مانند خيلی چيزهای ديگر در زندگی جواب اين سوال نيز می تواند این جمله باشد : « بستگی دارد ».
واقعيت اين است هيچ روش جادویی برای بهتر شدن روند ایجاد داستان های کاربری وجود ندارد ولی اين مطلب بدين معنا نيست که هيچ نوشته و مطلب مفيدی برای نوشتن داستان های کاربری وجود ندارد. بلکه فقط به اين معنی است که يک تئوری برای آموزش شما جهت بکارگيری يک روش خاص وجود ندارد.
خبر بد اينکه شکستن کارها به داستان های کاربری از جمله کارهای سختی است که فقط با تمرين می توان آن را ياد گرفت. البته خبر خوب هم اين است که تعدادی تکنيک وجود دارد که می توانيد با بکارگيری آنها امکان ايجاد داستان های کاربری خوب را افزايش دهيد.
سيستم به عنوان يک کيک چند لايه
یکی از محبوبترين چارچوب ها برای ايجاد داستان های کاربری که بر اساس فرضيه تفکر در مورد کاربر کار می کند، به شکل زير است که در آن دامنه کار و ارزشی که از اين کار نهايتا بدست خواهد آمد بيان می شود.
” به عنوان ……………. من می خواهم که ………. تا بتوانم …….”.
اين شروع خوبی است، اما ديدی در مورد چگونگی شکستن کارها به قطعات کوچک عملياتی و کاربردی که ارزشی را تحويل بدهد، تستها را امکانپذير کند، به تکامل محصول کمک کند و انعطاف پذيری برای تغيير دامنه را فراهم کند، به ما نمی دهد.
اينجا جايی است که “کيک چند لايه” وارد می شود. اين ايده اولين بار توسط بيل ويک در سال 2003 عنوان شد. اين مفهوم می گويد:
«کل سيستم را به عنوان يک کيک چند لايه در نظر بگيريد. به عنوان مثال لايه شبکه، لايه ماندگاری(Persistence)، لايه منطقی و لايه نمايش. ما می خواهيم تمام ماهيت کيک را به مشتری بدهيم. پس بهترين راه اين است که کيک را بصورت عمودی که شامل تمام لايه هاست برش دهيم. توسعه دهندگان اغلب تمايل به کار فقط بر روی يک لايه در هر زمان دارند ( و اين درست است)، اما به عنوان مثال لايه ديتابيس بدون داشتن لايه نمايش ارزش کمی را برای مشتری به همراه خواهد داشت.»
جنبه های منفی برش زدن افقی کيک
- شما نمی توانيد کيک را قبل از تمام شدنش امتحان کنيد: برش افقی کيک بدين معناست که سيستم شما لايه به لايه تحويل داده می شود. نقطه ضعف اين رويکرد اين است که مشتری تنها زمانی می تواند سيستم را درک کند که سيستم بطور کامل پياده سازی شده باشد. ترجیح روش چابک به ارائه حداقلی از ويژگی های مورد نياز جهت بازگشت سرمايه ارائه است. اين يعنی حداکثری کردن جريان(Flow) و ارزش محصول(Value).
- ممکن است وقتی کيک را امتحان می کنيد آن را دوست نداشته باشيد: کل کيک را بايد پخت قبل از اينکه مشتری بفهمد که آیا اين کيک واقعاً همان چيزی است که او می خواسته يا نه. به عبارت ديگر چرخه بازخورد بسيار بزرگ و طولانی است که منجر به افزايش ريسک می گردد. علاوه بر اين افزايش چرخه بازخورد اثر متضادی نسبت به ارزش هايی که ما در تفکر چابک دنبالش هستيم دارد. کل ايده اين است که ما ياد بگيريم و از اين دانش برای ايجاد تغييرات در محصول و در راستای تکامل آن استفاده کنيم. يک منبع اصلی و ضروری یادگيری همان دانشی است که از بازخوردهای مشتری حاصل می شود.
- شما نمی توانيد برشی که اول می خواهيد را انتخاب کنيد: تقريبا تنظيم و هماهنگ کردن داستان های افقی در لايه های مختلف و در راستای اولويت های در حال تغيير کسب و کار امری است غير ممکن و يا ناکارآمد. مونتاژ لايه به لايه سيستم انعطاف پذيريتان را کاهش داده و باعث دشوارتر شدن سازماندهی نقشه راه توسط مدير محصول می شود. مديران پروژه دائما در حال مبارزه و کشمکش با وابستگي ها و مديريت هوشمندانه ظرفيت تيم هستند که هر دو در پروژه های توسعه محصول بسيار شايع هستند. ادغام لايه های توسعه يافته به طور مستقل می تواند به يک کابوس تبديل شود و در نتيجه بر روی هزينه، زمان و بطور کلی بر روی کيفيت کل پروژه و نتايج آن تاثير منفی خواهد داشت.
يک تکه کيک شبيه چيست؟
اين نظريه، نظريه بسيار خوبيست. اما برای ايجاد موثرتر داستان ها نياز است که تعادلی ميان تئوری با تجربه های عملی و کاربردی برقرار ساخت. مدل Invest يک مثال خوب از اشتباه و مشکلات دنباله روی محض از يک نظريه است. اين مطلب بيان می کند که داستان خوب کاربری بايد: مستقل، قابل مذاکره، ارزش آفرين، تخمين پذير، کوچک و قابل تست باشد. البته درک اين نکته بسيار مهم است که بدانيم اين موارد در دنيای ايده آل وجود دارند.
زمانی که درباره داستان کاربری و مدل Invest صحبت می کنم، نمونه های بسياری را ديده ام که در آنها ارزش داستان های کاربری بيش از حد مورد توجه قرار گرفته است یا به عبارت ديگر، هر داستانی و بدون هيچ استثنایی بايد ارزش خود را به ارمغان بياورد.
برای مثال، اين ديدگاه سفت و سخت، زمانی که برای ساخت يک جريان ارتباطی -که در آن سيستم های مختلفی بايد با يکديگر در ارتباط هستند- بحث می کنيم، ممکن است با شکست مواجه شود. چرا که اگر تاکيد بيش از اندازه ای به ارزش داده شود ممکن است که يک داستان طولانی و پيچيده را تجربه کنيد که در آن نتايج زمانی حاصل می شود که کل جريان پياده سازی شده باشد. از منظر ارزش، اين امر منطقی به نظر می رسد، اما از منظر تست اين می تواند يک کابوس باشد. يکی ديگر از ناکامی های اين روش ممکن است مربوط به انگیزه های تيم شود، داستان های طولانی خسته کننده هستند و آنها را تشويق به تمرکز بر دانش و ايجاد سيلوهايی در داخل تيم می کند.
تاکيد بيش از حد بر “ارزش” نيز مانع از دريافت بازخوردهای سريع تيم چه از کاربران و و چه از سيستم های ديگر می شود. در چنين شرایطی ممکن است ترجيح دهيد به عنوان پيشرانه اصلی، کارتان را با استفاده از سطوح پيچيدگی به واحدهايی تقسيم کنيد. اين بدان معناست که کار از ساده ترين قسمت به سوی پيچيده‌ترين قسمت با رشد تدريجی پيچيدگی و بر اساس بازخوردهای منظم پيش می رود.
پيچيدگی سيستم در مقابل داستان های طولانی
ما داستان زير را برای ساخت يک ويژگی جديد برای وب سايتی که بليط های مسافرتی را بفروش می رساند استفاده می کنيم.
” به عنوان مشتری سايت مسافرتی،
می خواهم ليست پروازهای بين دو شهر انتخاب شده همراه با قيمت کل و مالياتهای آنها را مشاهده کنم
تا بتوانم بهترين گزينه را برای خودم انتخاب کنم.”
مورد بالا تسک ساده اي به نظر می آید. ساخت يک ليست همراه با اطلاعات خواسته شده در واسط کاربری(ui) سايت. با اين حال توليد اطلاعات مناسب نياز به منطقی قدرتمند، شامل لايه های مختلف، و گاهی چندين سيستم دارد، همانطور که در شکل زير نمايش داده شده است:
کار بسيار بزرگتر از آن است که به نظر می رسيد، و زمانی که توسعه دهندگان کار را آغاز می کنند، پيچيدگی ها رشد کرده و حتی نياز به تلاش بيشتری خواهد بود. در پايان داستان کاربری شما ممکن است خيلی طول بکشد. داستان های طولانی داستان های ديگر را مسدود و بلاک می کنند و اضطراب مشتری را نيز افزايش می دهند. علاوه بر اين ها، ممکن است مشکلاتی که در زمان هدايت تيم پيش می آيند پنهان شده و بالطبع محاسبه صحيح ظرفيت تيم دشوار خواهد شد.
زمانی که داستان ها بسيار بزرگ هستند، تمايل ذاتی و طبيعی برای برش افقی داستان وجود دارد و بدیهی است که ما اين را نمی خواهيم. ما هنوز می خواهيم داستان هارا به صورت متقاطع نگه داريم. اما چگونه اين کار را انجام دهيم بدون اينکه داستان های بزرگی ايجاد کنيم؟
کيک را چگونه برش بزنيم؟
دستورالعمل خاصی وجود ندارد، اما تعدادی استراتژی مفيد وجود دارد که می توانيد از آنها برای شکستن کار به داستان های کاربری استفاده کنيد.
- مراحل گردش کار
- قوانين کسب و کار
- مسير راضی / ناراضی
- انواع داده و پارامترها
- آپشن های ورودی / پلتفرم
- شرايط مبهم و پيوندها
مراحل گردش کار
هنگامی شکستن گردش کار به مراحل کوچکتر، بايد مراقب سطح جزيياتی که مورد استفاده قرار می دهيد باشيد. يک داستان می تواند فقط يک مرحله از گردش کار را که چيزهای مفيدی برای کاربر يا مشتری فراهم می کند، پوشش دهد. اگر فکر می کنيد تنها يک گام نمی تواند يک ارزش برای کسب و کار ايجاد کند احتمالا بايد چندين گام را برای ساخت داستانتان با هم گروه بندی کنيد.
گزينه متفاوت ديگری برای شکستن گردش کار وجود دارد. اما بايد دقت کنيد. همانطور که قبلا ذکر شد، گاهی اوقات بهتر است هر مرحله از جریان کار را در یک زمانی و بدون هیچ ارزش انفرادی ارائه دهیم.
يک استراتژی خوب برای کار با گردش کارهای پيچيده، شروع از يک جريان کار پايه و کاربردی و اضافه کردن مکرر لايه های جديدی از پيچيدگی به آن است، داستانهای بعدی يا اصلاحات را هم بر اساس بازخورد کاربران انتخاب کنید. همچنين می توانيد شاخه هاي مختلفی را داخل يک جريان کار جدا کنيد، مانند روش راضی/ ناراضی که بعداً شرح داده می شود. در شکل زير اين مفاهيم برای گردش کار خريد يک وب سايت تجاری نمايش داده شده است.
قوانين کسب و کار
هنگامی که کار خود را بر اساس قواعد کسب و کار تجزیه می کنيد بايد سعی کنيد بين قوانينی که اکثريت موارد را پوشش می دهد با قوانينی که فقط موارد مرزی را پوشش می دهند، تمايز قائل شويد. مشتريان اغلب نگران نگاشت شدن تمام موارداحتمالی هستند، چرا که گاهی اوقات فراموش می کنند که يک مورد مرزی می تواند با يک راه حل جايگزين و ارزانتر مورد عمل واقع شود.
کار را با قوانينی که رایج ترين سناريوها را و يا فرضيات اصلی شما را پوشش می دهند، آغاز کنيد و موارد بسيار خاص را به چرخه بعدی توسعه واگذار کنید. تست قوانين اساسی در شرايط واقعی زندگی يکی از بهترين شيوه های استخراج داده و اطلاعات برای شناسايی سناريوهای ديگری است که بايد پوشش دهيد و همچنين شناسايی قوانين اضافه ای که برای اجرا به آنها نياز داريم.
در زير مثالی از قوانينی که يک وب سايت تجاری برای تعيين رد يا پذيرش سفارشات بر اساس هزينه و يا پيچيدگی عمليات تحويل محصول مورد استفاده قرار میدهد، است. ما با اين فرض شروع می کنيم که هزينه های پايه حمل و نقل ما با فروش بيش از 5 دلار پوشش داده می شود. همچنين فرض می کنيم که حجم سفارشات خارجی کم است و قانونی برای اين مساله نداريم. اگر ما شروع به دريافت حجم بالای سفارشات خارج از کشور نکنيم ، قانون رد پذيرش سفارشات میتواند اتلاف وقت و انرژی باشد. اما برای اينکه مطمئن شويم، بايد اطلاعات دنيای واقعی را داشته باشيم.
مسير راضی / ناراضی :
چارچوب مسیر راضی/ ناراضی در شکستن داستانها مخصوصا زمانی که ساير روش ها کار نمی کنند، می تواند کمک کننده باشد. بايد توجه داشته باشيد که در بعضی از موارد نياز است که يک فرآيند دستی برای مقابله با مسیرهای ناراحت کننده تا زمان پياده سازی آن داشته باشيد.
به عنوان مثال، شما می توانيد امکان لاگين برای کاربر را از طريق يک عمليات ساده ثبت نام بدون حالت ويرايش فراهم کنيد. تا زمانی که امکان ويرايش برای کاربر را فراهم نکرده ايد احتمالاً بايد يک راه حل جايگزين داشته باشيد مانند ارسال ايميل پشتيبانی به يکی از افراد تيم تان. البته که اين راه حل، يک راه قابل گسترش نيست و يا امنيت خوبی را فراهم نمی کند، ولی یک راه حل موقتی است.
انواع داده ها يا پارامترها
اگر در حال پیاده سازی ويژگی های جستجو و یا فرم های ثبت نام هستيم، نوع داده ها (Data Type) راه حل ايده آلی برای شکستن داستان هاست. تحقیقات کاربر شما را قادر می سازد در مورد معيارهايی که در ساخت فيلترهای جستجو مورد استفاده هستند تصميم بگيريد.
وقتی کاربر سراغ فرم ثبت نام می رود با اطلاعات الزامی و ضروری شروع کند يا اين که کمک خواهد کرد به معتبر بودن فرضيات اصلی شما. مثال ديگر پياده سازی ويژگی های جستجو يا گزينه های فيلتر برای صفحه نتايج جستجو است. آخرين مورد در شکل زير نمايش داده شده است.
گزینه های ورودی / پلتفرم
پوشش چندين پلتفرم همزمان در دنیای واکنش گرای امروز امریست طبیعی. اما با تمرکز بر يک پلتفرم در يک زمان می توانيد همه چيز را ساده تر کنيد. از اين منطق برای شکستن کارها می توان استفاده نمود. برای پشتیبانی از اين تصميم از مخاطبين خود استفاده کنيد. برای مثال از پلتفرمی کار را شروع کنيد که بيشترين مخاطب را دارد. در حالت ايده آل شما می خواهيد از اين استراتژی در مراحل اوليه کار زمانی که در حال تاييد طراحی و ويژگی های اصلی محصول هستيد، استفاده کنيد. اگر تصميم در مورد طراحی واکنش گرا را خیلی دير اتخاذ کنيد ممکن است زمان و تلاش بيشتری را برای واکنش گرا شدن محصول صرف کنيد.
شرايط مبهم و پيوندها
شما همچنين می توانيد با مشخص تر کردن ايده های سطح بالا داستان ها را بشکنيد. اين کار به شما اجازه داشتن داستان های کوچکتر همراه با مزايايی نظير افزايش ارزش و افزايش سرعت بازخورد را می دهد. يکی ديگر از مزايای اين کار فراهم آمدن توسعه دهندگانی با تصورهای درست و شفاف درباره آنچه که در داستان انجام شده بايد تست شود، است.
ما می توانيم تعاريف زير را برای اين اصطلاحات در نظر بگيريم :
شرايط مبهم
به عنوان يک شخص هميشه در سفر، يک اپليکيشن هواشناسی می خواهم که داده های هواشناسی مربوط به چند روز را در خود ذخيره و آن را به صورت آفلاين نمايش دهد تا بتوانم زمانی که به مقصد رسيدم پيش بينی وضع هوا را ببينم حتی اگر موبايل من خط ندهد.
- داده های هواشناسی روز بعد ذخيره شود
- داده های هواشناسی تا پنج روز آينده ذخيره شود
پيوندها
به عنوان کاربری که بازمیگردم، شماره کارت اعتباری ام ذخيره شود و آن را برای خريدهای بعدی انتخاب کنم تا مجبور نباشم تمام شماره ها را در هر بار خريد تايپ کنم.
- ذخيره شماره کارت اعتباری در پروفايلم
- ارائه گزينه ای برای استفاده از شماره کارت اعتباری ذخيره شده هنگام خريد
ترجمه : حسین شاهرخی
