Story pointها در توسعه — چیست، مقیاسهای ارزیابی و کاربرد
Story pointها — واحدهای نسبی سنجش پیچیدگی وظایف در متدولوژیهای چابک توسعه هستند. برخلاف ساعتها، story pointها نه تنها زمان، بلکه پیچیدگی، ریسک و عدم قطعیت وظیفه را نیز در نظر میگیرند. به گفته Scrum.org، 2023، تیمهایی که از ارزیابی نسبی در story pointها استفاده میکنند، ۲۵٪ کمتر از تیمهایی که بر حسب ساعت ارزیابی میکنند، مهلتهای اسپرینت را از دست میدهند.
نکات کلیدی
- Story pointها — واحدهای نسبی پیچیدگی وظیفه، غیرمرتبط با زمان.
- مقیاسهای اصلی — فیبوناچی (۱، ۲، ۳، ۵، ۸، ۱۳، ۲۱) و خطی (۱، ۲، ۳، ۴، ۵).
- Velocity — تعداد story pointهایی که تیم در یک اسپرینت انجام میدهد، برای پیشبینی استفاده میشود.
- مزیت اصلی — story pointها به توسعهدهنده خاص وابسته نیستند و پیچیدگی را برای تیم منعکس میکنند.
- قاعده کلیدی — وظیفه مرجع مقیاس را تعیین میکند: تیم توافق میکند که ۱ story point چیست.
Story pointها چیستند؟
Story pointها — متریک پیچیدگی وظیفه هستند که در Scrum و سایر متدولوژیهای Agile استفاده میشوند. تیم هر وظیفه را نه بر حسب ساعت، بلکه در واحدهای نسبی ارزیابی میکند: «این وظیفه دو برابر وظیفه مرجع پیچیده است». چنین رویکردی تفاوت سرعت توسعهدهندگان مختلف را حذف میکند و بر پیچیدگی تمرکز میکند.
ریشه اصطلاح
مفهوم story point در اوایل دهه ۲۰۰۰ با رواج Scrum به وجود آمد. اولین بار ران جفریس آن را در چارچوب Extreme Programming (XP) توصیف کرد. ایده این بود که از ارزیابی «نفر-ساعت» که همیشه نادقیق است، به سمت پیچیدگی نسبی که تیم به صورت جمعی تعیین میکند حرکت کنیم. امروزه story pointها استاندارد صنعتی برای تیمهای Agile هستند.
عوامل در نظر گرفته شده در story pointها
در ارزیابی با story pointها، تیم سه عامل را در نظر میگیرد: حجم کار (مقدار کد، صفحهها، منطق)، پیچیدگی (چالشهای فنی، فناوریهای جدید) و عدم قطعیت (نیازمندیهای نامشخص، ریسکها). یک story point میتواند به معنای «وظیفه ساده بدون ریسک» باشد و ۸ — «وظیفه پیچیده با عدم قطعیت بالا».
مقیاسهای story point: چگونه انتخاب کنیم
انتخاب مقیاس story point بر دقت ارزیابی و راحتی برنامهریزی تأثیر میگذارد. محبوبترین مقیاس دنباله فیبوناچی است، اما گزینههای جایگزین نیز وجود دارند.
| مقیاس | مقادیر | مزایا | معایب |
|---|---|---|---|
| فیبوناچی | ۱، ۲، ۳، ۵، ۸، ۱۳، ۲۱ | افزایش طبیعی پراکندگی در وظایف بزرگ | برای تیمهای جدید پیچیده است |
| خطی | ۱، ۲، ۳، ۴، ۵ | ساده و قابل فهم | بدون پراکندگی برای وظایف بزرگ |
| توانی | ۱، ۲، ۴، ۸، ۱۶، ۳۲ | حداکثر پراکندگی در وظایف بزرگ | تشخیص وظایف بزرگ دشوار است |
| T-Shirt | S، M، L، XL | ارزیابی سریع تقریبی | نادقیق، نیاز به تبدیل دارد |
چرا فیبوناچی؟ روانشناسی مقیاس
دنباله فیبوناچی تصادفی انتخاب نشده است. تفاوت بین ۱ و ۲ حداقل است (۵۰٪)، اما بین ۱۳ و ۲۱ — قابل توجه (۶۲٪). این واقعیت را منعکس میکند: وظایف کوچک دقیقتر ارزیابی میشوند، وظایف بزرگ — با پراکندگی بیشتر. وقتی وظیفهای ۲۱ story point ارزیابی میشود، تیم میفهمد: «نمیدانیم چقدر طول میکشد، اما قطعاً بیشتر از ۱۳ است». مقیاس فیبوناچی از دقت کاذب جلوگیری میکند.
وظیفه مرجع — اساس مقیاس
برای اینکه مقیاس کار کند، تیم در مورد مرجع توافق میکند: «وظیفه X — ۱ story point است». معمولاً مرجع یک وظیفه ساده و آشنا انتخاب میشود: «اضافه کردن فیلد متنی به صفحه» یا «رفع باگ از نوع اشتباه تایپی». تمام وظایف دیگر نسبت به مرجع ارزیابی میشوند. بدون مرجع، story pointها معنی خود را از دست میدهند — هرکس واحد را به روش خود درک میکند.
Velocity تیم و پیشبینی
Velocity (سرعت تیم) — میانگین تعداد story pointهایی که تیم در یک اسپرینت انجام میدهد. این متریک کلیدی برای پیشبینی مهلتهای پروژه است.
Velocity چگونه محاسبه میشود
Velocity بر اساس وظایف تکمیلشده محاسبه میشود: story pointهای تمام وظایفی که تیم موفق به اتمام آنها شده (definition of done انجام شده) جمع میشوند. وظایف ناتمام در نظر گرفته نمیشوند. برای دقت، میانگین ۳-۵ اسپرینت آخر گرفته میشود. مثلاً اگر تیم در ۴ اسپرینت آخر ۲۰، ۲۲، ۱۸ و ۲۴ story point را تکمیل کرده باشد، velocity = ۲۱ sp.
پیشبینی با velocity
با دانستن velocity و حجم کل بکلاگ بر حسب story point، میتوان تعداد اسپرینتهای مورد نیاز تا انتشار را پیشبینی کرد. مثلاً اگر در بکلاگ ۲۱۰ story point وجود داشته باشد و velocity = ۲۱، به ۱۰ اسپرینت نیاز است. این یک پیشبینی تقریبی است که در طول کار دقیقتر میشود. مهم: velocity یک میانگین است، نه یک تعهد. با حد پایین (۱۸ sp) برنامهریزی کنید، نه با میانگین.
چگونه velocity را افزایش دهیم
Velocity را نمیتوان با دستور افزایش داد — این نشانه سلامت فرآیندها است. رشد پایدار velocity از طریق: کاهش بدهی فنی، بهبود فرآیندهای بازبینی کد، کاهش تغییر زمینه، خودکارسازی تست و CI/CD به دست میآید. مهم: velocity تیمهای مختلف قابل مقایسه نیست — هر تیم story pointها را به روش خود تعریف میکند.
Story pointها در مقابل ساعتها: چه و چه زمانی استفاده کنیم
Story pointها و ساعتها اهداف متفاوتی دارند و انتخاب بین آنها به زمینه بستگی دارد. تیمهای با تجربه از هر دو رویکرد برای وظایف مختلف استفاده میکنند.
چه زمانی story pointها بهتر عمل میکنند
Story pointها برای برنامهریزی اسپرینتها ضروری هستند: آنها به این وابسته نیستند که چه کسی وظیفه را انجام میدهد. Junior ممکن است روزانه ۲ sp انجام دهد، senior — ۴ sp، اما ارزیابی وظیفه برای هر دو ۲ sp باقی میماند. Story pointها امکان ردیابی بهرهوری تیم را بدون مقایسه توسعهدهندگان فراهم میکنند. این فشار سیاسی را کاهش میدهد و فضای تیم را بهبود میبخشد.
چه زمانی ساعتها ضروری هستند
ساعتها برای تعهدات خارجی ضروری هستند: قراردادها، برآورد هزینه، گزارشهای مشتری. مشتری میخواهد نه «۸ story point»، بلکه «۳ هفته» بداند. برای تبدیل story pointها به ساعتها از historical conversion rate استفاده میشود: تیم میداند که ۱ sp حدوداً ۴ ساعت کار است. تبدیل باید شفاف و مبتنی بر داده باشد، نه بر اساس حدس.
رویکرد ترکیبی
بسیاری از تیمها از رویکرد ترکیبی استفاده میکنند: وظایف برای برنامهریزی اسپرینت بر حسب story point ارزیابی میشوند، سپس مدیر آنها را برای گزارشدهی خارجی به ساعت/روز تبدیل میکند. مهم است که دو سیستم را در یک فرآیند مخلوط نکنید: یا بر حسب story point ارزیابی کنید و زمان را از velocity استخراج کنید، یا مستقیماً بر حسب ساعت ارزیابی کنید.
اشتباهات رایج هنگام کار با story pointها
پیادهسازی story pointها اغلب با اشتباهاتی همراه است که مزایای ارزیابی نسبی را از بین میبرند. در اینجا رایجترین آنها آورده شده است.
اتصال story pointها به زمان
رایجترین اشتباه — تیم توافق میکند: «۱ sp = ۴ ساعت». در این صورت story pointها معنی خود را از دست میدهند و به ساعتهایی با نام دیگر تبدیل میشوند. Story pointها باید نسبی باشند، به زمان متصل نباشند. اگر وظیفه A دو برابر وظیفه B پیچیده است، صرف نظر از چند ساعت کار، ۲ sp دریافت میکند.
ارزیابی پس از انجام
وقتی وظیفهای پس از انجام ارزیابی میشود — این ارزیابی نیست، تأیید واقعیت است. Story pointها باید قبل از شروع کار، در لحظه حداکثر عدم قطعیت تعیین شوند. ارزیابی پس از انجام velocity را مخدوش میکند و برای برنامهریزی مفید نیست. علاوه بر این، احساس کاذب دقت ایجاد میکند.
مقایسه velocity تیمهای مختلف
مقایسه velocity تیم A و تیم B — تمرینی بیمعنی است. هر تیم مرجع و مقیاس را به روش خود تعریف میکند. برای یک تیم ۱ sp یک وظیفه ساده یک ساعته است، برای دیگری — یک وظیفه یک روزه. فقط میتوان velocity یک تیم را در پویایی مقایسه کرد: افزایش یا کاهش مییابد.
مقیاس ناسازگار
وقتی وظایف مختلف با پیچیدگی یکسان story pointهای متفاوت دریافت میکنند و وظایف پیچیدهتر — کمتر، مقیاس خراب میشود. تیم باید به طور منظم مقیاس را کالیبره کند: هر ۳-۶ اسپرینت به صورت گذشتهنگر بررسی کند که ارزیابیها تا چه حد با پیچیدگی واقعی مطابقت داشتند. این کار سازگاری ارزیابیها را بهبود میبخشد.
سوالات متداول
یک story point چند ساعت است؟
Story pointها معادل ثابتی در ساعت ندارند. این یک واحد نسبی است: ۱ sp = پیچیدگی وظیفه مرجع. برای تبدیل به ساعت از historical conversion rate تیم خود استفاده کنید: میانگین ساعات کار در اسپرینت را بر velocity تقسیم کنید. معمولاً ۱ sp = ۴-۸ ساعت، اما این برای هر تیم منحصر به فرد است.
آیا میتوان از story pointها در Kanban استفاده کرد؟
بله، story pointها را میتوان در Kanban استفاده کرد، اما با محدودیتهایی. در Kanban اسپرینت ثابت وجود ندارد، بنابراین velocity نه برای اسپرینت، بلکه برای هفته یا ماه محاسبه میشود. تیمهای Kanban اغلب به جای story pointها از Cycle Time — زمان عبور وظیفه از ابتدا تا انتها استفاده میکنند. انتخاب به ویژگیهای تیم بستگی دارد.
اگر تیم نتواند بر سر ارزیابی به توافق برسد چه باید کرد؟
اگر ارزیابیها متفاوت است (یکی ۳ sp میدهد، دیگری ۱۳)، این نشانهای است که وظیفه به خوبی درک نشده است. وظیفه را به بخشهای کوچکتر تقسیم کنید. ریسکها و عدم قطعیتهایی که توسعهدهندگان مختلف میبینند را بحث کنید. اگر وظیفه بزرگ است، آن را به عنوان Spike (تحقیق ۲-۴ روزه) به جای story point ارزیابی کنید.
چگونه ارزیابی بر حسب ساعت را متوقف کنیم و به story pointها روی بیاوریم؟
انتقال ۳-۶ اسپرینت طول میکشد. با انتخاب مقیاس (فیبوناچی — safest choice) و تعیین وظیفه مرجع شروع کنید. ۲-۳ جلسه Planning Poker برگزار کنید. بعد از هر اسپرینت velocity را محاسبه کنید. Story pointها را به ساعت تبدیل نکنید — به تیم اجازه دهید به سیستم جدید عادت کند. بعد از ۳ اسپرینت خواهید دید چقدر برنامهریزی بهبود یافته است.
آیا ارزیابی وظیفه بر حسب story point پس از انجام تغییر میکند؟
خیر، ارزیابی تغییر نمیکند. Story pointها ارزیابی اولیه پیچیدگی هستند که قبل از شروع کار انجام میشود. پس از انجام وظیفه، ارزیابی ثابت میماند، حتی اگر تلاش واقعی متفاوت بوده باشد. تغییر ارزیابی پس از انجام آمار را مخدوش میکند و پیشبینی را بیمعنی میکند. تفاوتها را در retrospectives تحلیل کنید، اما ارزیابی را پس از واقع تغییر ندهید.
خلاصه
- Story pointها — واحدهای نسبی پیچیدگی، غیرمرتبط با زمان، اساس ارزیابی Agile.
- مقیاسهای اصلی — فیبوناچی (توصیه میشود)، خطی، توانی، T-Shirt sizing.
- Velocity — تعداد story point در اسپرینت؛ متریک کلیدی برای پیشبینی مهلتها.
- Story pointها در مقابل ساعتها — story pointها برای برنامهریزی اسپرینت، ساعتها برای تعهدات خارجی.
- اشتباهات رایج — اتصال به زمان، ارزیابی پس از انجام، مقایسه تیمها، مقیاس ناسازگار.
- وظیفه مرجع — اساس مقیاس؛ بدون آن story pointها معنی خود را از دست میدهند.
- مزیت کلیدی — story pointها به مجری وابسته نیستند و امکان تمرکز بر بهرهوری تیم را فراهم میکنند.
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید