مشکل بکلاگ تخت
وقتی صد یا دویست تسک همه با یک اولویت «بالا» در یک لیست تخت کنار هم باشند، برنامهریزی یعنی اسکرول کردن. ذینفع برای فهمیدن اینکه «کار پرداخت» به کجا رسیده، باید عنوان تکتک تسکها را بخواند و حدس بزند کدامها به آن مربوطاند. مدیر پروژه در جلسهٔ اسپرینت با سؤال «این چقدر مانده؟» میماند چون هیچ سطح جمعبندیای بین «تسک» و «کل پروژه» وجود ندارد.
اپیک دقیقاً همین سطح میانی را میسازد: یک واحد بزرگ کار — یک ویژگی، یک ابتکار — که چند تسک را زیر خودش جمع میکند. داستان کاربر همان تسکهاست، اما نوشتهشده از زاویهٔ کاربر نهایی («بهعنوان مشتری میخواهم با کارت پرداخت کنم») تا معیار پذیرش از ابتدا روشن باشد.
علائم نبود این ساختار
- ذینفع نمیتواند بدون خواندن دهها عنوان، پیشرفت یک ویژگی بزرگ را بفهمد.
- دو تسک که واقعاً به یک ابتکار مربوطاند، در دو گوشهٔ بکلاگ افتادهاند و کسی رابطهشان را نمیبیند.
- برآورد اسپرینت روی حس انجام میشود، نه روی مجموع امتیاز داستانهای واقعی.
- گزارش مدیریتی میگوید «۲۳٪ پیشرفت» بدون آنکه معلوم باشد کدام بخش کار واقعاً در ریسک است.
اپیک در مقابل اسپرینت — دو محور مستقل
نکتهٔ مهمی که اغلب اشتباه فهمیده میشود: اپیک و اسپرینت دو محور جدا هستند، نه یک سلسلهمراتب واحد. یک تسک همزمان میتواند به یک اپیک تعلق داشته باشد (چه کاری) و به یک اسپرینت (چه زمانی) و به یک ستون بورد (چه وضعیتی) — این سه محور مستقلاند و هرکدام سؤال متفاوتی را جواب میدهند. در WKFGo این استقلال بهصورت معماری واقعی پیاده شده: تسک به یک اپیک، یک اسپرینت و یک ستون همزمان وصل است، بدون آنکه یکی مانع دیگری شود.
چارچوب عملی برای ساختن بکلاگ
۱. اپیک را از نتیجهٔ کسبوکار تعریف کنید، نه از حجم کار. «پرداخت آنلاین» یک اپیک خوب است؛ «کارهای بکاند سهشنبه» یک اپیک نیست — آن یک برچسب زمانی است.
۲. هر داستان کاربر باید یک نتیجهٔ قابل مشاهده داشته باشد. «بهعنوان کاربر میخواهم رسید پرداخت را دانلود کنم» بهتر از «افزودن endpoint دانلود رسید» است — اولی معیار پذیرش را با خودش میآورد.
۳. امتیاز داستان را روی داستان بگذارید، نه روی اپیک. اپیک جمعبندی میشود؛ برآورد در سطح داستان دقیقتر و بحثپذیرتر است. مقایسهٔ امتیاز داستان با ساعت در امتیاز داستان در برابر ساعت باز شده.
۴. اسپرینت را از بکلاگ اپیکبندیشده پر کنید، نه از لیست تخت. وقتی تسکها زیر اپیک دستهبندی شدهاند، انتخاب اسپرینت یعنی «کدام اپیک الان اولویت دارد» — نه جستوجوی تصادفی در صد ردیف.
۵. وضعیت اپیک را هفتگی، نه روزانه، بازبینی کنید. اپیک درشتدانه است؛ بازبینی روزانهاش فقط نویز تولید میکند. جمعبندی پیشرفت اپیک باید از تعداد تسکهای تمامشده بهصورت خودکار محاسبه شود، نه گزارش دستی.
۶. اپیک بدون تاریخ پایان مشخص را علامت بزنید. اپیکی که نه تاریخ شروع دارد نه سررسید، معمولاً یعنی هنوز به اندازهٔ کافی تعریف نشده تا وارد برنامهریزی شود.
اشتباهات رایج
- اپیک را برابر با «پروژه» گرفتن — اپیک زیرمجموعهٔ پروژه است، نه معادل آن؛ یک پروژه معمولاً چند اپیک دارد.
- داستان کاربر نوشتن بدون معیار پذیرش — بدون آن، «تمامشده» تعریف مبهم میماند و بحث دوباره در بازبینی بالا میگیرد.
- گذاشتن صدها تسک زیر یک اپیک — اگر اپیک آنقدر بزرگ است که هفتهها بدون تغییر پیشرفت میماند، باید به چند اپیک کوچکتر تقسیم شود.
- بیتوجهی به اپیکهای بدون صاحب — هر اپیک باید یک نفر مسئول جمعبندی وضعیتش داشته باشد، نه اینکه مسئولیت بین کل تیم پخش شود.
نقش WKFGo، صادقانه
در WKFGo، اپیک یک لایهٔ مستقل و واقعی است — نه برچسب یا فیلتر ساختگی. هر اپیک آمار خودش را دارد (چند تسک، چه درصدی تمام شده) و مستقل از اسپرینت و ستون بورد کار میکند، پس تیم میتواند همزمان بپرسد «این اپیک چقدر پیش رفته» و «این اسپرینت چقدر ظرفیت دارد» بدون آنکه یکی جواب دیگری را خراب کند. این ساختار جایگزین انضباط تیم در نوشتن معیار پذیرش نمیشود — بدون داستان کاربر روشن، هیچ ابزاری تعریف «تمامشده» را برای شما نمیسازد.
پرسشهای متداول
آیا هر پروژه باید حتماً از اپیک استفاده کند؟ نه. برای پروژهٔ کوچک با کمتر از بیست تسک، لایهٔ اپیک معمولاً سربار اضافه است. وقتی بکلاگ از حدود پنجاه تسک عبور کند، فایدهٔ آن محسوس میشود.
تفاوت اپیک با پکیج کاری در WKFGo چیست؟ اپیک گروهبندی بر اساس ویژگی یا ابتکار محصول است؛ پکیج کاری بیشتر برای تفکیک تحویلهای قابلگزارش در پروژههای بزرگ به کار میرود. جزئیات پکیج در پروژهٔ بزرگ: فراتر از لیست تخت آمده.
آیا امتیاز داستان اجباری است؟ نه — تیمهایی که ترجیح میدهند با ساعت برآورد کنند میتوانند همان روش را ادامه دهند؛ نکتهٔ اصلی مقاله این است که برآورد در سطح داستان انجام شود، نه در سطح اپیک.