از ویژگیها به ارزش: تسلط بر برشدهی موارد مورد استفاده برای موفقیت آژیل
مقدمه
در دنیای پرسرعت توسعه نرمافزار، روشهای آژیل به استاندارد طلایی برای ارائه محصولات با کیفیت بالا که نیازهای در حال تکامل کاربران را برآورده میکنند، تبدیل شدهاند. با این حال، با وجود پذیرش گسترده روشهای آژیل، بسیاری از تیمها همچنان با یک چالش اساسی مواجه هستند: چگونه نیازهای پیچیده را به موارد کاری تقسیم کنند که هم به اندازهای کوچک باشند تا در طول یک اسپرینت انجام شوند و هم به اندازهای معنادار باشند تا ارزش واقعی به کاربران ارائه دهند.
رویکرد سنتی تقسیم ویژگیها به وظایف فنی یا صفحههای رابط کاربری، اغلب منجر به آنچه کارشناسان آن را «برش عمودی» مینامند—ایجاد موارد پشتیبانی که تنها گامهایی به سمت ارزش را نشان میدهند و خود ارزش را نمیسازند—میشود. تیمها خود را در حال ساخت قطعه به قطعه مییابند، تنها برای اینکه بفهمند کاربران تا زمانی که تمام قطعات جمعآوری شوند، هیچ فایدهای از آنها نمیگیرند. این الگوی معکوس، خود وعده اصلی آژیل را تضعیف میکند: ارائه نرمافزار کاربردی به طور مداوم و ارائه مداوم ارزش.
ورود برش مورد استفاده، مفهوم تحولآفرینی از استفاده از موارد 2.0 که رویکردی سیستماتیک برای تجزیه افقی ارائه میدهد. با برش همزمان نیازمندیها، طراحی، پیادهسازی و آزمون، تیمها میتوانند برشهای نازک افقی عملکردی را شناسایی کنند که در هر افزایش، ارزش کاربری از ابتدا تا انتها را ارائه میدهند. این مقاله به نظریه و عمل برش مورد استفاده میپردازد و نشان میدهد که چگونه این روش فاصله بین اهداف کاربری سطح بالا و کارهای توسعهای دقیق را پر میکند، در حالی که اصل آژیل ارائه مداوم ارزش را حفظ میکند.
از طریق تحلیل جامع، مثالهای واقعی و راهنماییهای عملی، بررسی خواهیم کرد که چرا برش مورد استفاده نشاندهنده تکاملی حیاتی در برنامهریزی آژیل است و چگونه تیمها میتوانند از این رویکرد برای دستیابی به نتایج بهتر، کاهش ریسک و حداکثر کردن بازگشت سرمایه بهره ببرند.
ضرورت برش: چرا مهم است
اکثر سیستمها نیازمند کارهای گستردهای هستند تا قابل استفاده شوند. آنها نیازمندیهای زیادی با اهمیت و اولویتهای متفاوت دارند و وابستگیهای زیادی بین آنها وجود دارد. سعی در ساخت چنین سیستمی به صورت یکجا، مسیری به شکست است. سیستم باید به صورت برشهایی ساخته شود که هر کدام ارزش مشخصی به کاربران ارائه دهند.
شکل ۱: رویکرد سنتی برش عمودی در مقابل برش افقی
دستورالعمل ساده است:
-
بیشترین کار مفیدی که سیستم باید انجام دهد را شناسایی کنید
-
آن را به برشهای نازکتر و قابل مدیریت تقسیم کنید
-
موارد آزمون را تعریف کنید که پذیرش این برشها را نشان دهند
-
بیشترین برش مرکزی را انتخاب کنید که از کل مفهوم عبور میکند
-
آن را به صورت تیمی تخمین بزنید و شروع به ساخت کنید
این رویکرد به طور اساسی تمرکز را از «چه ویژگیهایی میتوانیم بسازیم؟» به «چه ارزشی میتوانیم ارائه دهیم؟» تغییر میدهد. با اطمینان از اینکه هر برش منفعت ملموسی ایجاد میکند، تیمها تعهد ذینفعان را حفظ میکنند، فرضیات را به موقع تأیید میکنند و سرعت پایداری در ارائه ایجاد میکنند.
برش افقی در مقابل برش عمودی: تفاوت حیاتی
تفاوت بین برش مناسب و الگوی رایج معکوس «برش» برای موفقیت آژیل حیاتی است.
الگوی معکوس: برش عمودی
وقتی تیمها از استراتژی برش مورد استفاده استفاده نمیکنند، اغلب موارد پشتیبانی محصول را با «برش عمودی» به کاربرد به «گامهای کوچک به سمت ارزش» ایجاد میکنند. این کار به نظر آسان و طبیعی میآید زیرا:
-
مالکان محصول میتوانند به راحتی داستانهای کوچک کاربری برای این گامها بنویسند
-
طراحان رابط کاربری میدانند چگونه نقشههای صفحه برای هر گام طراحی کنند
-
توسعهدهندگان و آزمونکنندگان میتوانند به صورت مستقل این گامهای کوچک مورد استفاده را توسعه و آزمون کنند
با این حال، این رویکرد دو مشکل جدی ایجاد میکند:
-
کاربران هیچ چیز ارزشمندی دریافت نمیکنندتا زمانی که تمام گامها برای کل مورد استفاده توسعه و آزمون شوند
-
سرمایهگذاران بدترین بازگشت سرمایه ممکن را دریافت میکنند—سرمایهگذاری بزرگ در ابتدا بدون بازگشت تا پایان
این قانون طلایی آگیل را می شکند: هر اسپرینت باید چیزی تولید کند که بتوان آن را منتشر کرد.
شکل ۲: الگوی معکوس برش عمودی – مراحل بدون ارزش
[جایگزین تصویر که نشان می دهد برش عمودی چگونه عملکرد ناقصی ایجاد می کند که تا زمانی که به طور کامل مونتاژ شود، ارزشی برای کاربر ندارد]
روش صحیح: برش افقی
برش صحیح موارد مورد استفاده «افقی» است—هر برش نشان دهنده تعامل از ابتدا تا انتها است که به زیرمجموعه ای از کاربران امکان دستیابی به هدف خود را می دهد. این روش:
-
ارزش واقعی را در هر افزایش تحویل می دهد
-
امکان ارائه بازخورد زودهنگام از کاربران واقعی را فراهم می کند
-
ریسک پروژه را با اثبات ارزش در مراحل اولیه کاهش می دهد
-
بازگشت سرمایه بهتری برای سرمایه گذاران فراهم می کند
شکل ۳: برش افقی که ارزش از ابتدا تا انتها را تحویل می دهد
تفاوت بصری بسیار قابل توجه است: در حالی که برش عمودی اجزای فنی ناهمگن ایجاد می کند، برش افقی تجربیات کاربری یکپارچه ای را ایجاد می کند که به تنهایی می توانند وجود داشته باشند. هر برش داستان کاملی را از دیدگاه کاربر روایت می کند.
برش چگونه در عمل کار می کند
مرحله ۱: شناسایی موارد مورد استفاده
با ایجاد یک نمودار مدل مورد استفاده شروع کنید که نشان دهد:
-
کاربران چه کسانی هستند (اعمال)
-
اهدافی که باید به دست آورند چیست
-
دامنه و هدف راه حل
برای مثال، در یک سیستم درخواست وام دانشجویی، مورد استفاده اصلی «درخواست وام دانشجویی» خواهد بود.
شکل ۴: نمودار مدل مورد استفاده که اعمال و اهداف را نشان می دهد
این دیدگاه کلی اطمینان حاصل می کند که همه متوجه هدف سیستم شوند و به شناسایی موارد مورد استفاده که بیشترین ارزش حیاتی را ارائه می دهند کمک می کند. این نقشه راهی برای اولویت بندی است و از اینکه تیم ها قبل از درک نیازهای کاربران در جزئیات فنی گم شوند جلوگیری می کند.
مرحله ۲: شناسایی داستان ها
یک مورد مورد استفاده، داستان های مرتبط متعددی با اهمیت و اولویت متفاوت را پوشش می دهد. داستان ها راه های خاصی را برای دستیابی به هدف مورد استفاده نشان می دهند—هم چگونگی موفقیت و هم نحوه برخورد با مشکلاتی که در طول مسیر پیش می آیند.
برای مورد استفاده «قرض گرفتن کتاب» در یک سیستم کتابخانه، داستان ها می توانند شامل موارد زیر باشند:
-
قرض گرفتن کتاب با موفقیت (جریان اصلی)
-
حداکثر تعداد ثبت قرض گرفتن رسیده است (جریان استثنا)
-
قرض گیرنده جریمه دارد (جریان استثنا)
شکل ۵: داستان های مورد استفاده که جریان های اصلی و استثنا را نشان می دهند
[جایگزین تصویر که نمودار جریان یا جدولی را نشان می دهد که مسیرهای مختلف داستان ها در یک مورد مورد استفاده را نشان می دهد، و جریان موفقیت اصلی و مسیرهای جایگزین/استثنا را برجسته می کند]
شناسایی این داستان ها نیازمند همکاری بین مالک محصول، توسعه دهندگان، آزمون کنندگان و متخصصان حوزه است. هدف این است که نه تنها مسیر موفقیت را ثبت کنیم، بلکه سناریوهای واقعی که کاربران با آن مواجه خواهند شد، از جمله شرایط خطا و موارد لبه را نیز در نظر بگیریم.
مرحله ۳: ایجاد برش ها
یک برش مورد استفاده، یک یا چند داستان از یک مورد استفاده انتخاب شده است که به عنوان یک مأموریت کاری با ارزش واضح برای مشتری تشکیل میدهد. برش باید به صورت همکاری با ذینفعان انجام شود تا اطمینان حاصل شود که هر برش ارزش ایجاد میکند.
از مورد استفاده «قرض گرفتن کتاب»، برشها ممکن است به این صورت باشند:
| مورد استفاده | داستانهای مورد استفاده | برش مورد استفاده |
|---|---|---|
| قرض گرفتن کتاب | قرض گرفتن کتاب (اصلی) | موفقیت در قرض گرفتن کتاب |
| قرض گرفتن کتاب | حداکثر تعداد ثبت قرض گرفتن رسیده است | شکست در قرض گرفتن کتاب |
| قرض گرفتن کتاب | قرضگیر باید جریمه بپردازد | شکست در قرض گرفتن کتاب |
هر برش به عنوان جایگزین تمام کارهای مورد نیاز—نیازمندیها، طراحی، پیادهسازی و آزمون—برای تکمیل داستانهای انتخاب شده عمل میکند.
شکل ۶: ماتریس انتخاب برش مورد استفاده
نکته کلیدی اینجا این است که یک برش نیازی به شامل کردن تمام داستانهای یک مورد استفاده ندارد. بلکه باید داستانهای کافی را شامل شود تا تجربهای هماهنگ و ارزشمند ایجاد کند. گاهی یک داستان به تنهایی یک برش کامل را تشکیل میدهد؛ در حالی که گاهی داستانهای متعددی باید ترکیب شوند تا ارزش ایجاد شود.
مرحله ۴: اختصاص به اسپرینتها
برشها میتوانند به اندازهای تنظیم شوند که در یک اسپرینت یا ستون کانبان جای گیرند. یک برش میتواند یک داستان یا چند داستان را شامل شود—مکانیزم برش به اندازهای انعطافپذیر است که برشهایی به اندازههای مورد نیاز برای پیشبرد توسعه، چه بزرگ و چه کوچک، ایجاد شود.
شکل ۷: برنامهریزی اسپرینت با برشهای مورد استفاده
این انعطافپذیری به تیمها اجازه میدهد تا به سرعت و ظرفیت خود تطبیق یابند، در حالی که اصل اینکه هر افزایش ارزش ایجاد کند، حفظ شود. تیمها میتوانند دقت برش را بر اساس پیچیدگی، خطر و اولویتهای ذینفعان تنظیم کنند.
مثالهای دنیای واقعی
پلتفرم تجارت الکترونیک: پرداخت مهمان
در رویکرد برش مورد استفاده، ویژگی «پرداخت مهمان» ممکن است به این صورت برش داده شود:
مورد استفاده: پرداخت
-
برش ۱: مهمان یک مورد را به سبد خرید اضافه میکند و خرید را تکمیل میکند (جریان اصلی)
-
ارزش: مهمان میتواند بدون ایجاد حساب خرید کند
-
آزمون: مهمان پرداخت را تکمیل میکند و تأییدیه دریافت میکند
-
-
قسمت 2: مهمان کد تخفیف را در حین پرداخت اعمال میکند (جایگزین)
-
ارزش: عملکرد تخفیف
-
آزمون: کد تخفیف تخفیف را به مجموع سبد خرید اعمال میکند
-
-
قسمت 3: مهمان تأییدیه ایمیل دریافت میکند (جایگزین)
-
ارزش: دیده شدن سفارش برای مهمان
-
آزمون: ایمیل تأییدیه با جزئیات صحیح تحویل داده شد
-
شکل 8: استراتژی تقسیمبندی خرید مهمان در فروشگاه آنلاین
توجه کنید که هر قسمت به تنهایی ارزش قابل توجهی ایجاد میکند. پس از قسمت 1، مهمانان میتوانند واقعاً خرید کنند. پس از قسمت 2، میتوانند پول صرفهجویی کنند. پس از قسمت 3، دسترسی به سوابق سفارش دارند. هر افزایش تجربه کاربری را بهبود میبخشد بدون اینکه قسمتهای بعدی ضرورتاً باید کار کنند.
اپلیکیشن بانکی موبایل: انتقال پول
مورد استفاده: انتقال منابع
-
قسمت 1: انتقال پایه بین حسابهای خود
-
ارزش: کاربر پول را در داخل سیستم انتقال میدهد
-
آزمون: انتقال در تعادل هر دو حساب نمایش داده میشود
-
-
قسمت 2: انتقال به مشتری دیگر (جایگزین)
-
ارزش: کاربر پول را به صورت خارجی ارسال میکند
-
آزمون: دریافتکننده منابع را دریافت میکند
-
-
قسمت 3: مدیریت کمبود موجودی (استثنا)
-
ارزش: مدیریت ملایم خطاها
-
آزمون: پیام خطا نمایش داده میشود؛ هیچ وجهی انتقال نمییابد
-
شکل 9: تقسیمبندی انتقال بانکی موبایل با پیشرفت ارزش
این مثال نشان میدهد که چگونه مدیریت خطاها میتواند خود به عنوان یک قسمت ارزشمند باشد. هرچند ممکن است عجیب به نظر برسد که سناریوهای خطا را اولویت دهیم، اما شکست ملایم برای اعتماد و رضایت کاربر بسیار حیاتی است. کاربرانی که با پیامهای خطا واضح و مفید مواجه میشوند، تجربه بهتری نسبت به کاربرانی دارند که با سقوط سیستم گیجکننده مواجه میشوند.
تأثیر بر مدیریت لیست اولویتهای محصول
وقتی با اسکرام استفاده شود، قسمتهای مورد استفاده به عنوان آیتمهای اولویتدهی شده محصول در نظر گرفته میشوند. این کار مزایای متعددی ایجاد میکند:
زمینه ارزش روشن
مدل مورد استفاده، نشانگری بزرگ و مشهود از هدف راهحل ارائه میدهد و نشان میدهد:
-
کی کاربران هستند
-
اهدافی که باید به دست آورند
-
زمینه ارزش هر مورد در لیست پیشنیاز
این امکان اولویتبندی شیءمند را فراهم میکند: «تمرکز اولیه بر مهمترین موارد استفاده، امکان بهبود و آمادهسازی بخش بالای لیست پیشنیاز را فراهم میکند تا اولین گامها را بگذارند.»
شکل ۱۰: لیست پیشنیاز محصول با اولویتبندی شده و به صورت طبقهبندی شده بر اساس برشهای مورد استفاده
بدون این زمینه، موارد لیست پیشنیاز به عنوان ویژگیهای منزوی و رقابتی برای توجه ظاهر میشوند. با برش موارد استفاده، رابطه بین موارد مشخص میشود و تصمیمگیریهای اولویتبندی با اهداف استراتژیک کاربران همخوانی میکند نه با راحتی عملیاتی.
آزمون و انتشار مستقل
هر برش میتواند به صورت مستقل توسعه و آزمون شود. این امر به توسعه مبتنی بر آزمون پذیرش کمک میکند، جایی که موارد آزمون به تعریف و تأیید هر برش کمک میکنند.
شکل ۱۱: موارد آزمون پذیرش همراستا با برشهای مورد استفاده
این همراستایی تضمین میکند که آزمون بر ارزش کاربر تمرکز کند نه فقط صحت فنی. هنگامی که یک برش آزمونهای پذیرش خود را با موفقیت گذراند، ذینفعان میتوانند با اطمینان بگویند که ارزش مورد نظر را ارائه میدهد.
بهروزرسانی بهموقع
تیمها میتوانند موارد لیست پیشنیاز محصول را به برشهای نازکتر تقسیم کنند، هر کدام همچنان ارزش جدیدی برای کاربر نهایی ارائه میدهند. راهنمایی واضح است: «تمام موارد استفاده را بهطور همزمان نکنید. فقط به اندازهای برشها را شناسایی کنید که نیازهای فوری تیم را برآورده کند.»
شکل ۱۲: فرآیند بهروزرسانی بهموقع برای برشهای مورد استفاده
این رویکرد از اتلاف ناشی از برنامهریزی بیش از حد جلوگیری میکند و همچنین تضمین میکند که تیم همیشه کارهای شفاف و ارزشمندی آماده داشته باشد. این اصل، اصل آژیل را در برابر پایبندی به برنامه به تصویر میکشد.
برشبندی در عصر هوش مصنوعی
ارزش دارد اشاره کنیم که هرچند برشبندی برای توسعه دستی طراحی شده است که در آن توسعهدهندگان انسانی به موارد کاری کوچک و قابل مدیریت نیاز دارند، اما توسعه کمکشده توسط هوش مصنوعی این معادله را تغییر میدهد. هنگامی که هوش مصنوعی پیادهسازی را تولید میکند، تیمها میتوانند به صورت همزمان با کل مورد استفاده کار کنند و نیازی به برشهای کوچک نیست.
با این حال، مفهوم برشبندی همچنان برای موارد زیر ارزشمند است:
-
برنامهریزی و تخمین: درک حوزه کار
-
اولویتبندی: تعیین اینکه چه چیزی اولین بار بیشترین ارزش را ارائه میدهد
-
مدیریت ریسک: ارائه عملکرد بحرانیترین بخشها به موقع
-
ارتباط با ذینفعان: نشان دادن پیشرفت به صورت ارزش قابل اندازهگیری
شکل ۱۳: برشبندی مورد استفاده در جریانهای کاری توسعه کمکشده توسط هوش مصنوعی
حتی با شتاب بخشیدن هوش مصنوعی، چالش اساسی تعیین اینکه اولین بار چه چیزی باید ساخته شود، همچنان وجود دارد. برشبندی یک چارچوب برای اتخاذ این تصمیمات بر اساس ارزش نه تنها راحتی فنی ارائه میدهد. علاوه بر این، ذینفعان هنوز به دیدن پیشرفت تدریجی نیاز دارند و برشها واحدهایی برای نمایش و بازخورد ارائه میدهند که پروژهها را همراستا با نیازهای کاربر نگه میدارند.
مطالعه موردی: تحول در مهاجرت یک سیستم قدیمی
برای نشان دادن قدرت برشبندی مورد استفاده در عمل، فرض کنید یک شرکت خدمات مالی که از یک سیستم قدیمی پردازش وام به یک پلتفرم مدرن مبتنی بر ابر مهاجرت میکند.
چالش
سیستم قدیمی صدها نوع وام با قوانین کسب و کار پیچیده که در طی 20 سال جمع آوری شده بود، مدیریت میکرد. پروژه انتقال شامل موارد زیر بود:
-
انتقال بیش از 50,000 وام فعال
-
اجرای الزامات جدید انطباق قوانین
-
بهروزرسانی رابط کاربری برای کارشناسان وام
-
یکپارچهسازی با APIهای جدید ارزیابی اعتبار
تلاشهای اولیه برای انتقال، از رویکرد عمودی سنتی پیروی میکرد: ابتدا ساختار پایگاه داده را منتقل کردند، سپس لایه منطق کسبوکار و سپس رابط کاربری. پس از شش ماه و سرمایهگذاری قابل توجه، تیم زیرساخت را منتقل کرده بود اما نتوانستند یک وام را بهطور کامل و از ابتدا تا انتها پردازش کنند. ذینفعان نگران شدند و پروژه به خطر انقراض کشید.
مداخله برشبندی
یک رهبر تیم جدید، برشبندی موارد مورد استفاده را معرفی کرد و با یک کارگاه مدلسازی مورد استفاده که شامل کارشناسان وام، متخصصان انطباق و توسعهدهندگان بود، شروع به کار کرد. آنها پنج مورد استفاده اصلی را شناسایی کردند:
-
پردازش درخواست وام جدید
-
بررسی و تأیید وام
-
خدمات وامهای موجود (پرداختها، تغییرات)
-
تولید گزارشهای انطباقی
-
مدیریت عدم پرداخت وام
به جای تلاش برای انتقال همه چیز، آنها «پردازش درخواست وام جدید» را به عنوان مورد استفاده با بیشترین ارزش انتخاب کردند و شروع به برشبندی افقی آن کردند.
شکل 14: مدل مورد استفاده برای انتقال سیستم قدیمی
تعریف و اجرای برشها
تیم برشهای زیر را برای «پردازش درخواست وام جدید» تعریف کرد:
برش 1: درخواست وام شخصی ساده
-
پشتیبانی از وامهای شخصی پایه با اسناد استاندارد
-
یکپارچهسازی با یک API کارگزاری اعتبار
-
فرآیند تأیید دستی
-
ارزش: کارشناسان وام میتوانند رایجترین نوع وام (60٪ حجم) را پردازش کنند
-
مدت زمان: 3 هفته
برش 2: تصمیمگیری خودکار برای درخواستهای با ریسک پایین
-
افزودن تأیید خودکار برای درخواستهایی که معیارهای پیشفرض را دارند
-
یکپارچهسازی منابع داده اضافی برای ارزیابی ریسک
-
ارزش: زمان پردازش را از روزها به دقایق برای ۴۰٪ درخواستها کاهش دهید
-
مدت زمان: ۲ هفته
برش ۳: انواع وام پیچیده (وسایل نقلیه، وام مسکن)
-
گسترش برای پشتیبانی از وامهای خودرو و وام مسکن با مستندات تخصصی
-
افزودن پشتیبانی از همدرخواستدهنده
-
ارزش: پوشش بقیه ۴۰٪ حجم درخواستها
-
مدت زمان: ۴ هفته
برش ۴: مدیریت استثناها و موارد لبهای
-
مدیریت درخواستهای ناقص، اسناد گمشده و شرایط خاص
-
افزودن جریانهای ارتقاء
-
ارزش: سیستم قوی که پیچیدگیهای دنیای واقعی را مدیریت میکند
-
مدت زمان: ۳ هفته
شکل ۱۵: نقشه راه تقسیمبندی درخواست وام با زمانبندی تحویل ارزش
نتایج و درسهای آموخته شده
پس از اتمام برش ۱، تیم سیستمی کارآمد را نمایش داد که درخواستهای واقعی وام را پردازش میکرد. کارشناسان وامها بازخورد فوری در مورد مشکلات کاربرپسندی ارائه دادند که در برشهای بعدی برطرف شدند. تا پایان برش ۲، سیستم ۴۰٪ درخواستهای جدید را با تصمیمات خودکار پردازش میکرد و بهبود قابل اندازهگیری در کارایی ایجاد کرد.
نتایج کلیدی شامل موارد زیر بود:
-
تحویل ارزش اولیه: عملکرد کاربردی در عرض ۳ هفته به جای ۶+ ماه در دسترس بود
-
اعتماد ذینفعان: نمایشهای منظم اعتماد را افزایش داد و تأمین مالی مداوم را تضمین کرد
-
کاهش ریسک: چالشهای فنی در زمانی کشف شدند که اصلاح مسیر هنوز امکانپذیر بود
-
پذیرش کاربران: کارشناسان وام به صورت تدریجی آموزش دیدند هنگامی که قابلیتهای جدید به دسترسی قرار گرفتند
-
تحقيق بازگشت سرمایهبهبودهای بهرهوری از هفته چهارم به بعد شروع به تجمع کرد
شکل ۱۶: مقایسه قبل و بعد – رویکرد انتقال عمودی در مقابل انتقال برشخورده
انتقال با موفقیت در مجموع ۱۴ هفته انجام شد، به طوری که سیستم به طور کامل فعال بود و همه انواع وام پشتیبانی میشدند. مهمتر از همه، سازمان رویکرد جدیدی به پروژههای پیچیده یاد گرفت که آن را در پروژههای بعدی به کار برد.
بهترین روشها برای اجرای برشبندی موارد استفاده
با توجه به اجرای موفق و اصول ذکر شده در بالا، اینجا بهترین روشها برای تیمهایی که از برشبندی موارد استفاده میکنند آورده شده است:
۱. با اهداف کاربر شروع کنید، نه ویژگیها
همیشه با درک اینکه کاربران چه چیزی را میخواهند به دست آورند شروع کنید. ویژگیها وسیلهای برای رسیدن به هدف هستند؛ اهداف کاربران خود هدف هستند. بپرسید: «این چه مشکلی را حل میکند؟» و «کی از آن بهرهمند میشود؟»
۲. همکاری بین رشتهها
برشبندی نیازمند ورودی از صاحبان محصول، توسعهدهندگان، آزمونکنندگان، طراحان و متخصصان حوزه است. هیچ نقش واحدی دید کاملی از اینکه چه چیزی یک برش ارزشمند را تشکیل میدهد، ندارد.
شکل ۱۷: همکاری چندتخصصی در کارگاههای تعریف برشها
۳. هر برش را به صورت مستقل اعتبارسنجی کنید
مطمئن شوید که هر برش میتواند به صورت کامل و بدون وابستگی به برشهای آینده آزمون شود. اگر برشی برای نشان دادن ارزش به عملکرد ناقص نیاز داشته باشد، احتمالاً بسیار باریک است یا به درستی تعریف نشده است.
۴. تعادل بین اندازه برش و ارزش آن
برشها باید به اندازهای کوچک باشند که در یک اسپرینت به پایان برسند، اما به اندازهای بزرگ که ارزش معناداری ایجاد کنند. اگر برشی احساس میشود که بیاهمیت است، آن را با داستانهای مرتبط ترکیب کنید. اگر احساس میشود که بسیار سنگین است، به نقاط طبیعی تقسیمبندی نگاه کنید.
۵. حفظ ردیابی
ارتباطات واضحی بین برشها، موارد استفاده والد آنها و اهداف کسبوکاری که پشتیبانی میکنند حفظ کنید. این ردیابی به تصمیمگیریهای اولویتبندی کمک میکند و به ذینفعان کمک میکند تا منطق استراتژیک پشت لیست پیشنیازها را درک کنند.
شکل ۱۸: ماتریس ردیابی که برشها را به موارد استفاده و اهداف کسبوکاری متصل میکند
۶. اندازهگیری را متناسب با زمینه تنظیم کنید
همه موارد استفاده نیازمند یک سطح یکسان برشبندی نیستند. موارد استفاده با خطر بالا و ارزش بالا از برشبندی دقیقتر بهرهمند میشوند تا بتوانند به زودی اعتبارسنجی شوند. موارد استفاده با اولویت پایینتر میتوانند از برشهای کلیتر استفاده کنند تا هزینههای اداری کاهش یابد.
۷. پیشرفت را به صورت ارزشمحور اعلام کنید
هنگام گزارش پیشرفت، بر ارزشی که برشهای تکمیل شده ایجاد کردهاند تأکید کنید، نه بر نقاط فنی که به دست آمدهاند. بگویید «کاربران اکنون میتوانند خرید را به صورت مهمان تکمیل کنند» به جای «انتقال پایگاه داده ۶۰٪ انجام شده است».
خطاهای رایج و نحوه جلوگیری از آنها
حتی با نیت خوب، تیمها ممکن است در هنگام اجرای برشبندی موارد استفاده به اشکال بیفتند. اینجا خطاهای رایج و استراتژیهای کاهش آنها آورده شده است:
اشکال ۱: برشبندی بیش از حد نازک
مشکلایجاد برشهایی به اندازهای کوچک که ارزش قابل توجهی ایجاد نکنند، به طور اساسی دوباره ایجاد کردن برشبندی عمودی با اصطلاحات متفاوت.
راهحلاز آزمون «آیا میتوانیم این را منتشر کنیم؟» استفاده کنید. اگر برشی اگر به صورت مستقل منتشر شود ارزشی ایجاد نکند، احتمالاً بسیار نازک است. داستانهای مرتبط را تا زمانی که تجربه کاربری منسجمی داشته باشید، ترکیب کنید.
اشکال ۲: نادیده گرفتن جریانهای استثنا
مشکل: تمرکز فقط بر سناریوهای مسیر موفق و به تأخیر انداختن مدیریت خطاهای نامطلوب به طور نامحدود، که منجر به سیستمهای ناپایدار میشود.
راهحل: جریانهای مهم خطا را در برشهای اولیه شامل کنید. کاربران به طور مداوم با خطاها مواجه میشوند و مدیریت ملایم آنها بخشی از ارزش ارائهشده است.
خطای ۳: برشبندی بیش از حد در ابتدا
مشکل: تلاش برای برشبندی جزئی تمام موارد استفاده قبل از شروع توسعه، که منجر به بیحرکتی تحلیلی میشود.
راهحل: اصل بهروزرسانی بهموقع را دنبال کنید. فقط آنچه برای چند اسپرینت بعدی نیاز است را برش دهید، تا بتوانید از یادگیری از برشهای اولیه برای راهنمایی برشهای بعدی استفاده کنید.
شکل ۱۹: ریتم بهینه برشبندی – بهروزرسانی بهموقع
خطای ۴: از دست دادن دید کلی
مشکل: آنقدر بر برشهای فردی تمرکز کردن که مدل کلی موارد استفاده و اهداف استراتژیک محو شوند.
راهحل: به طور منظم به مدل موارد استفاده بازگردید تا مطمئن شوید برشها با موارد استفاده با اولویت بالا و اهداف کسبوکار هماهنگ هستند. مدل را قابل دیدن و بهروز نگه دارید.
خطای ۵: رفتار کردن با برشها به عنوان الزامات ثابت
مشکل: تعریف برشها به شکل سفت و سخت و مقاومت در برابر تطبیق بر اساس بازخورد یا شرایط تغییرکرده.
راهحل: اصل انعطافپذیری در برابر تغییر را بپذیرید. آماده باشید برشها را دوباره تعریف کنید، اولویتبندی مجدد کنید یا حتی آنها را حذف کنید بر اساس اطلاعات جدید.
اندازهگیری موفقیت با استفاده از برشبندی موارد استفاده
برای ارزیابی اینکه آیا برشبندی موارد استفاده مزایای مورد انتظار را ارائه میدهد یا خیر، این معیارها را ردیابی کنید:
معیارهای تحویل ارزش
-
زمان تا اولین ارزش: چه مدت از شروع پروژه تا زمانی که کاربران به مزیت ملموس دست پیدا کنند؟
-
ارزش در هر اسپرینت: ارزش کسبوکار قابل اندازهگیری که در هر افزایش تحویل داده میشود
-
رضایت ذینفعان: بازخورد منظم در مورد اینکه برشهای تحویلشده مطابق انتظارات هستند یا خیر
معیارهای کیفیت
-
نرخ فرار عیب: تعداد عیوب شناسایی شده پس از انتشار نسبت به زمان توسعه
-
پوشش تست: درصد تستهای پذیرش برشها که به صورت خودکار انجام شده و موفقیتآمیز هستند
-
درصد کار دوباره: مقدار کاری که به دلیل درک نادرست نیازها دوباره انجام شده است
شاخصهای کارایی
-
پیشبینیپذیری: تفاوت بین تخمین و تلاش واقعی برای برشها
-
کارایی جریان: نسبت زمان فعال کار به کل زمان چرخه
-
فرارانس انتشار: چند بار در هر زمان افزایشهای ارزشمند به محیط تولید میرسند
شکل 20: داشبورد شاخصهای کلیدی موفقیت برشبندی موارد مورد استفاده
این شاخصها باید به بهبود مستمر روش برشبندی کمک کنند. اگر زمان تا اولین ارزش همچنان بالا باشد، برشها ممکن است بزرگتر از حد مطلوب باشند. اگر نرخ عیوب افزایش یابد، برشها ممکن است تست کافی نداشته باشند. بازبینیهای منظم باید این شاخصها را بررسی کرده و روشهای عملیاتی را متناسب با آنها تنظیم کنند.
نتیجهگیری
برشبندی مورد استفاده نشاندهنده تغییر بنیادی در نحوه نگاه تیمهای آگیل به تجزیه نیازها و ارائه ارزش است. با انتقال از برش عمودی—که در آن موارد کار نشاندهنده مراحل فنی بدون ارزش مستقل هستند—به برش افقی—که در آن هر افزایش عملکرد کاربری پایان به پایان را ارائه میدهد—تیمها به پتانسیل واقعی روشهای آگیل دست مییابند.
شواهد قانعکننده هستند: سازمانهایی که از برشبندی مورد استفاده استفاده میکنند، زمان ورود به بازار سریعتر، رضایت بیشتر ذینفعان، کاهش ریسک پروژه و بازگشت سرمایه بهتری تجربه میکنند. این روش، انضباط در تفکر درباره ارزش را تقویت میکند، همکاری بین رشتهها را تشویق میکند و درک مشترکی از اینکه چه چیزی برای کاربران مهمتر است، ایجاد میکند.
شکل 21: مسیر از توسعه متمرکز بر ویژگی به توسعه متمرکز بر ارزش
همانطور که از توضیحات نظری، مثالهای عملی و یک مطالعه موردی دقیق دیدیم، برشبندی مورد استفاده تنها یک تکنیک نیست، بلکه یک دیدگاه است. این روش نیازمند این است که تیمها به طور مداوم بپرسند: «چه ارزشی ارائه میدهیم؟» به جای اینکه بپرسند: «چه ویژگیهایی در حال ساخت هستیم؟» این سوال، هرچند ساده به نظر میرسد، نحوه تفکر، برنامهریزی، اجرا و ارزیابی کار را تغییر میدهد.
در آینده، اصول برشبندی مورد استفاده همچنان مرتبط خواهند ماند، حتی با تحولات در روشهای توسعه. در عصر کدنویسی کمکشده توسط هوش مصنوعی، پلتفرمهای کمکد و ابزارهای سریعسازی نمونهسازی، چالش انتخاب اولین چیزی که باید ساخته شود—و اطمینان از ارائه ارزش—به مراتب بیشتر اهمیت پیدا میکند، نه کمتر. برشبندی چارچوبی برای اتخاذ این تصمیمات به صورت سیستماتیک به جای تصادفی فراهم میکند.
برای تیمهایی که در پذیرش آگیل مشکل دارند، به ویژه آنهایی که متوجه میشوند اسپرینتها فعالیت ایجاد میکنند اما ارزش ایجاد نمیکنند، برشبندی مورد استفاده مسیری اثباتشده برای پیشروی ارائه میدهد. این روش فاصله بین دیدگاه استراتژیک و اجرای عملیاتی، بین نیازهای کاربر و پیادهسازی فنی، و بین برنامهریزی و تحویل را پر میکند.
مسیر با یک سوال شروع میشود: «ارزشمندترین چیزی که کاربران ما نیاز دارند چیست، و ضخامت کمترین برش آن که اکنون میتوانیم تحویل دهیم چیست؟» به این سوال به طور مداوم پاسخ دهید، و نه تنها فرآیند توسعه خود را تغییر میدهید، بلکه توانایی خود را در ساخت محصولاتی که واقعاً به کاربران خود خدمت میکنند، تقویت میکنید.
همانطور که منشور آگیل به ما یادآوری میکند، بالاترین اولویت ما، رضایت مشتری از طریق تحویل زودهنگام و مداوم نرمافزار ارزشمند است. برشبندی مورد استفاده مکانیزم عملی است که این امید را ممکن میسازد. این کار قول آگیل را به واقعیت تحویل مداوم ارزش تبدیل میکند، یک برش در هر بار.
منابع
- مورد استفاده 2.0: راهنمای ضروری برای توسعه موفق نرمافزار: راهنمای جامع که برشبندی مورد استفاده را به عنوان مفهوم اصلی در توسعه آگیل معرفی میکند و توضیح میدهد که چگونه موارد مورد استفاده را به افزایشهای ارزشمندی که عملکرد پایان به پایان را ارائه میدهند، تقسیم کرد.
- برآورد و برنامهریزی آگیل: بررسی دقیق روشهای برنامهریزی آگیل شامل تقسیم داستان، ردیابی سرعت و برنامهریزی انتشار که روشهای برشبندی مورد استفاده را تکمیل میکنند.
- نقشهبرداری داستان کاربر: داستان کامل را کشف کنید، محصول درستی بسازید: راهنمای عملی برای دیداری کردن مسیر کاربر و تقسیم آن به برشهای قابل اجرا، که تکنیکهای تکمیلی برای مدیریت لیست اولویتها در برشبندی مورد استفاده ارائه میدهد.
- هنر توسعه آگیل: منبع جامع در مورد رویکردهای آگیل که شامل توسعه تکراری، بازخورد مداوم و اولویتبندی مبتنی بر ارزش است و با اصول برشدهی موارد مورد استفاده همخوانی دارد.
- مقیاسگذاری توسعه لین و آگیل: تفکر و ابزارهایی برای پروژههای بزرگمقیاس: بینشهایی در مورد به کارگیری اصول آگیل و لین در مقیاس بزرگ، از جمله استراتژیهای مدیریت نیازهای پیچیده از طریق ارائه ارزش به صورت تدریجی.
- توسعه مبتنی بر آزمون پذیرش: توضیحی در مورد روشهای ATDD که با ایجاد برشهای مورد استفاده همپوشانی دارند و اطمینان حاصل میکنند که هر برش به وضوح تعریف و تأیید شود، با استفاده از معیارهای پذیرش قابل اندازهگیری.
- تحویل مداوم: انتشار نرمافزارهای قابل اعتماد از طریق خودکارسازی ساخت، آزمون و نصب: راهنمایی برای ایجاد خطوط تحویل که امکان انتشار مکرر برشهای مورد استفاده را فراهم میکنند و اصل آگیل تحویل مداوم ارزش را پشتیبانی میکنند.
- این مقاله بخشی از مجموعهای از مقالات است که به بررسی یکپارچهسازی Use-Case 2.0 با رویکردهای توسعه آگیل میپردازد.
