کارهای توسعه خود را به مانند یک کیک چند لایه برش بزنید

در پروژه های چابک (Agile)، هدف به واحدهای جداگانه ای از کار که توصیف کننده یک ویژگی یا توانایی انجام یک عمل  از دیدگاه کاربر نهایی است، شکسته میشود. این واحدهای کاری را معمولا داستان کاربری (user story) می‌نامند.

اکنون یک سوال پیش می آید: بهترین راه برای شکستن کارها به داستانهای کاربری چیست؟ مانند خیلی چیزهای دیگر در زندگی جواب این سوال نیز می تواند این جمله باشد : « بستگی دارد ».

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

خبر بد اینکه شکستن کارها به داستان های کاربری از جمله کارهای سختی است که فقط با تمرین می توان آن را یاد گرفت. البته خبر خوب هم این است که تعدادی تکنیک وجود دارد که می توانید با بکارگیری آنها امکان ایجاد داستان های کاربری خوب را افزایش دهید.

سیستم به عنوان یک کیک چند لایه

یکی از محبوبترین چارچوب ها برای ایجاد داستان های کاربری که بر اساس فرضیه تفکر در مورد کاربر کار می کند، به شکل زیر است که در آن دامنه کار و ارزشی که از این کار نهایتا بدست خواهد آمد بیان می شود.

” به عنوان ……………. من می خواهم که ………. تا بتوانم …….”.

این شروع خوبی است، اما دیدی در مورد چگونگی شکستن کارها به قطعات کوچک عملیاتی و کاربردی که ارزشی را تحویل بدهد، تستها را امکانپذیر کند، به تکامل محصول کمک کند و انعطاف پذیری برای تغییر دامنه را فراهم کند، به ما نمی دهد.

اینجا جایی است که “کیک چند لایه” وارد می شود. این ایده اولین بار توسط بیل ویک در سال ۲۰۰۳ عنوان شد. این مفهوم می گوید:

«کل سیستم را به عنوان یک کیک چند لایه در نظر بگیرید. به عنوان مثال لایه شبکه، لایه ماندگاری(Persistence)، لایه منطقی و لایه نمایش. ما می خواهیم تمام ماهیت کیک را به مشتری بدهیم. پس بهترین راه این است که کیک را بصورت عمودی که شامل تمام لایه هاست برش دهیم. توسعه دهندگان اغلب تمایل به کار فقط بر روی یک لایه در هر زمان دارند ( و این درست است)، اما به عنوان مثال لایه دیتابیس بدون داشتن لایه نمایش ارزش کمی را برای مشتری به همراه خواهد داشت.»

جنبه های منفی برش زدن افقی کیک

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

 یک تکه کیک شبیه چیست؟

این نظریه، نظریه بسیار خوبیست. اما برای ایجاد موثرتر داستان ها نیاز است که تعادلی میان تئوری با تجربه های عملی و کاربردی برقرار ساخت. مدل Invest یک مثال خوب از اشتباه و مشکلات دنباله روی محض از یک نظریه است. این مطلب بیان می کند که داستان خوب کاربری باید: مستقل، قابل مذاکره، ارزش آفرین، تخمین پذیر، کوچک و قابل تست باشد. البته درک این نکته بسیار مهم است که بدانیم این موارد در دنیای ایده آل وجود دارند.

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

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

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

پیچیدگی سیستم در مقابل داستان های طولانی

ما داستان زیر را برای ساخت یک ویژگی جدید برای وب سایتی که بلیط های مسافرتی را بفروش می رساند استفاده می کنیم.

” به عنوان مشتری سایت مسافرتی،

می خواهم لیست پروازهای بین دو شهر انتخاب شده همراه با قیمت کل و مالیاتهای آنها را مشاهده کنم

تا بتوانم بهترین گزینه را برای خودم انتخاب کنم.”

مورد بالا تسک ساده ای به نظر می آید. ساخت یک لیست همراه با اطلاعات خواسته شده در واسط کاربری(ui) سایت. با این حال تولید اطلاعات مناسب نیاز به منطقی قدرتمند، شامل لایه های مختلف، و گاهی چندین سیستم دارد، همانطور که در شکل زیر نمایش داده شده است:

کار بسیار بزرگتر از آن است که به نظر می رسید، و زمانی که توسعه دهندگان کار را آغاز می کنند، پیچیدگی ها رشد کرده و حتی نیاز به تلاش بیشتری خواهد بود. در پایان داستان کاربری شما ممکن است خیلی طول بکشد. داستان های طولانی داستان های دیگر را مسدود و بلاک می کنند و اضطراب مشتری را نیز افزایش می دهند. علاوه بر این ها، ممکن است مشکلاتی که در زمان هدایت تیم پیش می آیند پنهان شده و بالطبع محاسبه صحیح ظرفیت تیم دشوار خواهد شد.

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

کیک را چگونه برش بزنیم؟

دستورالعمل خاصی وجود ندارد، اما تعدادی استراتژی مفید وجود دارد که می توانید از آنها برای شکستن کار به داستان های کاربری استفاده کنید.

• مراحل گردش کار
• قوانین کسب و کار
• مسیر راضی / ناراضی
• انواع داده و پارامترها
• آپشن های ورودی / پلتفرم
• شرایط مبهم و پیوندها

مراحل گردش کار

هنگامی شکستن گردش کار به مراحل کوچکتر، باید مراقب سطح جزییاتی که مورد استفاده قرار می دهید باشید. یک داستان می تواند فقط یک مرحله از گردش کار را که چیزهای مفیدی برای کاربر یا مشتری فراهم می کند، پوشش دهد. اگر فکر می کنید تنها یک گام نمی تواند یک ارزش برای کسب و کار ایجاد کند احتمالا باید چندین گام را برای ساخت داستانتان با هم گروه بندی کنید.

گزینه متفاوت دیگری برای شکستن گردش کار وجود دارد. اما باید دقت کنید. همانطور که قبلا ذکر شد، گاهی اوقات بهتر است هر مرحله از جریان کار را در یک زمانی و بدون هیچ ارزش انفرادی ارائه دهیم.

یک استراتژی خوب برای کار با گردش کارهای پیچیده، شروع از یک جریان کار پایه و کاربردی و اضافه کردن مکرر لایه های جدیدی از پیچیدگی به آن است، داستانهای بعدی یا اصلاحات را هم بر اساس بازخورد کاربران انتخاب کنید. همچنین می توانید شاخه های مختلفی را داخل یک جریان کار جدا کنید، مانند روش راضی/ ناراضی که بعداً شرح داده می شود. در شکل زیر این مفاهیم برای گردش کار خرید یک وب سایت تجاری نمایش داده شده است.

قوانین کسب و کار

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

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

در زیر مثالی از قوانینی که یک وب سایت تجاری برای تعیین رد یا پذیرش سفارشات بر اساس هزینه و یا پیچیدگی عملیات تحویل محصول مورد استفاده قرار میدهد، است. ما با این فرض شروع می کنیم که هزینه های پایه حمل و نقل ما با فروش بیش از ۵ دلار پوشش داده می شود. همچنین فرض می کنیم که حجم سفارشات خارجی کم است و قانونی برای این مساله  نداریم. اگر ما شروع به دریافت حجم بالای سفارشات خارج از کشور نکنیم ، قانون رد پذیرش سفارشات میتواند اتلاف وقت و انرژی باشد. اما برای اینکه مطمئن شویم، باید اطلاعات دنیای واقعی را داشته باشیم.

مسیر راضی / ناراضی :

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

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

انواع داده ها یا پارامترها

اگر در حال پیاده سازی ویژگی های جستجو و یا فرم های ثبت نام هستیم، نوع داده ها (Data Type) راه حل ایده آلی برای شکستن داستان هاست. تحقیقات کاربر شما را قادر می سازد در مورد معیارهایی که در ساخت فیلترهای جستجو مورد استفاده هستند تصمیم بگیرید.

وقتی کاربر سراغ فرم ثبت نام می رود با اطلاعات الزامی و ضروری شروع کند یا این که کمک خواهد کرد به معتبر بودن فرضیات اصلی شما. مثال دیگر پیاده سازی ویژگی های جستجو یا گزینه های فیلتر برای صفحه نتایج جستجو است. آخرین مورد در شکل زیر نمایش داده شده است.

 

گزینه های ورودی / پلتفرم

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

شرایط مبهم و پیوندها

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

ما می توانیم تعاریف زیر را برای این اصطلاحات در نظر بگیریم :

شرایط مبهم

به عنوان یک شخص همیشه در سفر، یک اپلیکیشن هواشناسی می خواهم که داده های هواشناسی مربوط به چند روز را در خود ذخیره و آن را به صورت آفلاین نمایش دهد تا بتوانم زمانی که به مقصد رسیدم پیش بینی وضع هوا را ببینم حتی اگر موبایل من خط ندهد.

• داده های هواشناسی روز بعد ذخیره شود
• داده های هواشناسی تا پنج روز آینده ذخیره شود

پیوندها

به عنوان کاربری که بازمیگردم، شماره کارت اعتباری ام ذخیره شود و آن را برای خریدهای بعدی انتخاب کنم تا مجبور نباشم تمام شماره ها را در هر بار خرید تایپ کنم.

• ذخیره شماره کارت اعتباری در پروفایلم
• ارائه گزینه ای برای استفاده از شماره کارت اعتباری ذخیره شده هنگام خرید

ترجمه : حسین شاهرخی

منبع