به آخرین باری که به یک سفر جاده‌ای رفتید فکر کنید. آیا دقیقاً به همان اندازه‌ای که فکر می‌کردید طول کشید یا به اتفاقات پیش‌بینی نشده‌ای مانند ترافیک و بدی آب و هوا و... برخوردید؟ برنامهریزی و تخمین‌زدن در پروژه‌ها نیز دقیقاً به همین شکل است. موانعی که انتظارش را نداریم و عدم قطعیت‌هایی که پیش می‌آید می‌توانند زمان‌بندی پروژه ما را به تعویق بیندازند و شاید گاهی ما را به شکلی عمیقی در مشکلات درگیر کنند.
شاید به یکباره ببینیم در جایی قرار داریم که اصلاً فکرش را نمی‌کردیم. مثلاً بودجه پروژه تمام شده باشد یا کیفیت کار خروجی، فرسنگ‌ها با چیزی که فکر می‌کردیم تفاوت دارد.
در این مواقع است که تکنیک‌های تخمین‌زدن پا به میدان می‌گذارند. با روش‌های تخمین کارها مانند استوری پوینت / Story Point، میتوان حدومرز تسکها را تعیین کرد تا به ما و تیممان بگوید چقدر تلاش (افورت) برای انجام هر وظیفه نیاز است و کجا ممکن است مسائل و مشکلاتی بروز کنند.
بیایید با هم به سراغ بررسی استوری پوینتها و چگونگی استفاده از آنها برویم.
استوری پوینت چیست؟
استوری پوینتها روشی برای تخمین‌زدن میزان تلاشی است که برای کامل‌کردن یک یوزر استوری استفاده میشود. داستان کاربر همان کوچک‌ترین بخش‌های کار در توسعه یک محصول هستند که تعداد زیادی از آنها باید انجام شود تا توسعه یک محصول تا حد زیادی کامل شود.
Story Point نقطه مقابل نگاه سنتی به برنامهریزی و مدیریت پروژه است که در آن کارها را بر اساس میزان زمان موردنیازشان تخمین زده می‌شد. این روش را توسعه‌دهنده‌ای به نام ران جفریس / Ron Jeffries ابداع کرد.
شما معمولاً باید استوری پوینتها را قبل از جلسه برنامه ریزی اسپرینت تخمین زده باشید. چرا که در این جلسه باید میزان کاری را که می‌توانید در یک اسپرینت انجام دهید، مشخص کنید. پس باید از قبل تخمین‌های خود را زده باشید تا در جلسه در مورد آن بحث و تصمیم‌گیری شود.
تخمین استوری پوینت در مقابل تخمین ساعتی
استوری پوینت در اسکرام واحدهای اندازه‌گیری «میزان تلاش لازم برای انجام کامل تسکها» هستند. تیمها Story Pointها را بر اساس میزان فعالیت، نوع کار و ریسک‌های موجود در روند کار تخمین می‌زنند.
در این روش «روزها و ساعتها» نمی‌توانند به‌عنوان واحد اندازه‌گیری تخمین یک تسک استفاده شوند، زیرا آنها دانش، تخصص یا تلاشی که برای تکمیل یک پروژه لازم است را در نظر نمی‌گیرند. اعضای یک تیم اجایل بر اساس میزان چالش یک تسک و نه بر اساس مقدار زمان صرف‌شده، با استوری پوینتها پاداش میگیرند. این رویکرد، تیم را بر «تحویل ارزش» متمرکز میکند نه زمان صرف شده که بعضاً ممکن است بی‌ثمر باشد.
نحوه نمایش استوری پوینتها
استوری پوینت‌های اجایل معمولاً بر اساس دنباله فیبوناچی نمایش داده میشوند. در این دنباله، هر عدد برابر است با مجموع دو عدد قبلی خود. این دنباله به شکل زیر است:
۰, ۱, ۱, ۲, ۳, ۵, ۸, ۱۳, ۲۱, ۳۴, ۵۵, ۸۹, ۱۴۴...
به دلیل فاصله زیاد بین اعداد، تشخیص آنها آسان‌تر است و تیم میتواند راحت‌تر بر سر انتخاب عدد مناسب برای تخمین کارهای خود به توافق برسد.
بسیاری از تیمهای اجایل نسخه اصلاح‌شده دنباله فیبوناچی را استفاده میکنند:
۱, ۲, ۳, ۵, ۸, ۱۳, ۲۰, ۴۰ و ۱۰۰
در این مدل، حداقل استوری پوینت برابر ۱ و حداکثر استوری پوینت برابر ۱۰۰ است.
فاکتورهای اساسی در تخمین استوری پوینت
معمولاً استوری پوینتها سه عامل اصلی را در نظر میگیرند که می‌توانند بر محدوده و تلاش موردنیاز برای انجام یک وظیفه تأثیر بگذارند. ارزش Story Point در اسکرام نیز متناسب با این سه مورد افزایش می‌یابد. ازآنجاکه استوری پوینتها نسبی هستند، ارزش آنها با درنظرگرفتن این جزئیات و مقایسه تسکهای مشابه تعیین میشود:
-
ریسک: منظور میزان ریسک یا عدم قطعیتی است که با تسک مرتبط است. برای مثال، اگر تسک یا انجام آن به‌گونه‌ای مرتبط با افراد ثالث، پیمانکاران قراردادی یا ذی‌نفعان پروژه باشد، ممکن است میزان ریسک آن تسک افزایش یابد. چراکه مدیریت‌کردن این همه متغیر عدم قطعیت را بالا می‌برد و نمی‌توان تخمین دقیقی زد.
-
تکرارپذیری: تجربه تیم در انجام تسکهای مشابه مهم است. تیم باتجربه‌تر تخمین‌های دقیق‌تری می‌زند.
-
پیچیدگی تسک: سطح دشواری تسک و میزان وضوح اهداف آن نیز تأثیرگذار است و حتی تیمهای باتجربه نیز در تسکهای پیچیده دچار چالش‌هایی در تخمین میشوند.
استوری پوینتها نسبی هستند، به این معنا که ارزش نسبی و نسبت آنها با یکدیگر اهمیت دارد، نه مقدار عددی واقعی آنها.
مالک محصول در فرایند تخمین استوری پوینتها مشارکت خواهد داشت، اما خود او استوری پوینت‌های اجایل را تخمین نمی‌زند؛ بلکه این یک تلاش تیمی است. اعضای تیم اجایل که قرار است بر روی داستان‌های کاربری (یوزر استوری) کار کنند، بهتر از همه قادر به تخمین تلاش موردنیاز برای انجام تسک هستند. در این حالت، مالک محصول بیشتر بر روی برنامهریزی اسپرینت و اولویتبندی آیتم‌های بک‌لاگ محصول که تیم توسعه باید روی آنها کار کند، تمرکز میکند.
شش گام عملی برای پیاده‌سازی و تخمین استوری پوینتها
حالا که با Story Pointها آشنا شدید، بیایید بررسی کنیم که چگونه می‌توانیم آنها را برای تعیین یوزر استوری تخمین بزنیم.
-
معرفی استوری پوینتها به تیم
درک قوی از استوری پوینتها برای موفقیت ضروری است. برای راحت‌تر کردن این فرایند برای تیم، اصول اولیه و مزایای استوری پوینتها را برای آنها توضیح دهید. به‌خصوص، اطمینان حاصل کنید که آنها متوجه شوند که اعداد استوری پوینتها باید بهصورت نسبی نسبت به یکدیگر تنظیم و مقیاس‌بندی شوند.
نکته مهم:
به یاد داشته باشید که نسبت‌ها در استوری پوینتها مهم هستند، نه مقادیر عددی واقعی. به عبارت دیگر، یک تسکی که استوری پوینت 2 دریافت میکند باید دو برابر بیشتر از تسکی که استوری پوینت ۱ دارد، تلاش ببرد.
-
تعیین مقیاس استوری پوینتها
همان‌طور که گفتیم، مقیاس‌بندی استوری پوینتها میتواند بر اساس «دنباله فیبوناچی» باشد و این تکنیک برای تخمین در اجایل بسیار محبوب است؛ اما از آنجایی که ممکن است این تکنیک برای برخی از تیمها پیچیده باشد، روش‌های دیگری نیز وجود دارند.
اگر مقادیر عددی، تیم شما را گیج میکند، می‌توانید از روش «سایزبندی تیشرت» استفاده کنید که تلاش انجام تسکها را بر اساس اندازه‌های تیشرت تخمین می‌زند. مانند:
ایکس اسمال/XS (خیلی کوچک)، اسمال/S، مدیوم/M، لارج/L، ایکس لارج/XL و دو ایکس لارج/XXL.
-
ایجاد یک ماتریس استوری پوینت
ماتریس استوری پوینتها از دنباله استوری پوینتها می‌آید و به‌عنوان یک نقطه مرجع برای جلسه پلنینگ عمل میکند و کمک میکند تصویر واضح‌تری از نحوه امتیازدهی به هر تسک داشته باشید.
نکته مهم:
ماتریس استوری پوینتِ شما، به مرور زمان و با اجرای اسپرینت‌ها تکامل می‌یابد و به شما کمک میکند درک بهتری از تلاش مرتبط با انواع تسک‌هایی که انجام می‌دهید پیدا کنید. نگران نباشید که اولین بار کاملاً بی‌نقص باشد. ماتریس را بر اساس تسکهای معمولی تیم خود بسازید و برنامهریزی کنید. سپس بعد از هر اسپرینت ماتریس را دوباره ارزیابی کنید.
|
استوری پوینت |
تلاش موردنیاز |
زمان موردنیاز |
پیچیدگی تسک |
ریسک یا عدم قطعیت |
|
۱ |
حداقل تلاش |
چند دقیقه |
پیچیدگی کم |
هیچ |
|
۲ |
حداقل تلاش |
چند ساعت |
پیچیدگی کم |
هیچ |
|
۳ |
تلاش متوسط |
یک روز |
پیچیدگی نسبتاً کم |
کم |
|
۵ |
تلاش متوسط |
چند روز |
پیچیدگی متوسط |
متوسط |
|
۸ |
تلاش زیاد |
یک هفته |
پیچیدگی متوسط |
متوسط |
|
۱۳ |
حداکثر تلاش |
یک ماه |
پیچیدگی بالا |
زیاد |
-
برگزاری جلسه برنامهریزی پوکر
حالا که دنباله استوری پوینتها را انتخاب کرده‌اید و ماتریس استوری پوینتها را ایجاد کرده‌اید، وقت آن است که به اصل موضوع بپردازید:
تخمین استوری پوینتها با برگزاری جلسه پوکر برنامه ریزی / Planning Poker
هدف از پوکرِ برنامهریزی این است که استوری پوینتها را به یوزر استوری‌ها اختصاص دهید، تیمتان را توجیه و با خود همراه کنید و در مورد اینکه تیم شما میتواند چه تعداد تسک را در اسپرینت آینده انجام دهد، ایده‌پردازی کنید.
همه اعضای تیم می‌توانند در مورد کارهای آینده اعلام نظر کنند. با مشارکت‌دادن کل تیم، مطمئن می‌شویم که استوری پوینتها بر اساس نظرات مختلف و غیر سوگیرانه مدیریت میشوند.
چگونه یک جلسه پوکر برنامهریزی موفق برگزار کنیم:
-
به تیم خود یک ماتریس Story Point مشخص به‌عنوان مرجع و یک مجموعه کارت که دنباله استوری پوینت شما را نمایش می‌دهد بدهید. شما می‌توانید کارت‌ها را خودتان بسازید یا دانلود کنید.
-
یک «داستان کاربر / User Story» را انتخاب کنید.
-
استوری را با تیم خود به بحث بگذارید و بگویید شامل چه مواردی است و موفقیت آن در چه صورت خواهد بود.
-
از هر عضو تیم بخواهید که کارت استوری پوینتی که احساس میکند نمایانگر میزان تلاش لازم برای تکمیل آن استوری است را به طور خصوصی انتخاب کند. منظور از بین کارت‌ها با شماره 1، 2، 3، 5، 8، 13، 21 و... است.
-
از تیم بخواهید کارت‌های انتخابی خود را هم‌زمان فاش کنند. اگر استوری پوینتها به هم نزدیک بودند و تخمین اعضای گروه با یکدیگر هم‌راستا بود، یعنی همین تخمین منطقی است و باید به سراغ تخمین یوزر استوری بعدی رفت. اما اگر استوری پوینت‌های اعضا هم‌راستا نباشد، بحث در مورد یوزر استوری را آن‌قدر ادامه دهید و دلایل خود را بگویید تا در نهایت به توافق برسید.
-
این فرایند را تکرار کنید و به تمام تسکهای موجود در بک لاگ محصول یک استوری پوینت اختصاص دهید.
-
با استفاده از ماتریسِ استوری پوینت خود به‌عنوان مرجع، تعداد تسک‌هایی را که تیم شما میتواند در اسپرینت آینده انجام دهد، تعیین کنید.
نکته مهم:
-
برنامهریزی و اجرای اسپرینت
اگر برای اولین بار از Story Pointها استفاده می‌کنید، تا زمانی که اولین اسپرینت را کامل انجام نداده‌اید، دقیقاً نمی‌دانید که چه تعداد استوری پوینت می‌توانید در هر اسپرینت انجام دهید که به این مفهوم سرعت اسپرینت / Sprint Velocity گفته میشود. مشکل خاصی نیست. در جلسه برنامهریزی اسپرینت، تخمین‌های خود را دست بالا بگیرید و در اسپرینتهای بعدی به‌مرور خود را در تخمینها بهبود دهید.
نکته مهم:
اسپرینت اول شما ممکن است شامل تعداد بالایی از استوری پوینت‌های کم‌ارزش، تعداد کمی استوری پوینت‌های پرارزش یا ترکیبی از آنها باشد. به مرور زمان، شما خواهید آموخت که چه چیزی برای تیم شما بهتر است و فرایند را بر اساس بازخورد تیم خود بهبود خواهید داد.
-
بهبود مستمر تخمین استوری پوینتها
پس از انجام اولین اسپرینت با استفاده از استوری پوینتها، وقت آن است که به موضوع اصلی چارچوب اجایل بپردازید: بهبود مستمر.
برای انجام این کار، با تیم خود جمع شوید و در مورد آنچه که خوب پیش رفته و آنچه که نیاز به بهبود دارد صحبت کنید. شما می‌توانید یک جلسه جداگانه برای این کار برگزار کنید یا آن را در جلسه رترو اسپرینت خود بگنجانید.
سؤالاتی مانند اینکه آیا استوری پوینتها به‌درستی مشخص شده‌اند؟ چه مشکلات غیرمنتظره‌ای در پروژه پیش آمده‌اند؟ و دلایل دیگر عدم رسیدن به اهداف را از تیم خود بپرسید. از پاسخ‌های تیم برای بهبود فرایندها در اسپرینت بعدی استفاده کنید. اگر نیاز است، دنباله استوری پوینت یا ماتریس استوری پوینت خود را دوباره ارزیابی کنید.
از یافته‌های خود برای تخمین «سرعت اسپرینت» یا تعداد استوری پوینتهایی که تیم شما میتواند در هر اسپرینت انجام دهد استفاده کنید. برای مثال، اگر تیم شما چهار استوری پوینت در روز انجام می‌دهد، سرعت اسپرینت شما ۴۰ استوری پوینت در اسپرینت دو هفته‌ای است (با درنظرگرفتن 10 روز کار در دو هفته).
نکته مهم:
مثال عملی از تخمین استوری پوینتها برای یک تیم توسعه نرم‌افزار
در ادامه یک مثال عملی می‌بینیم از تخمین استوری پوینتها برای تیمی که در حال توسعه یک اپلیکیشن مدیریت تسک است. این تیم شامل یک توسعه‌دهنده ارشد، دو توسعه‌دهنده بک‌اند، یک توسعه‌دهنده فرانت‌اند، و یک طراح UI/UX است.
تعریف یوزر استوری
تیم با همکاری مالک محصول لیستی از داستان‌های کاربر را آماده میکند. برای مثال:
-
ثبت‌نام کاربر: کاربران باید بتوانند با استفاده از ایمیل خود ثبت‌نام کنند.
-
ورود کاربر: کاربران باید بتوانند با استفاده از ایمیل و رمز عبور وارد شوند.
-
افزودن تسک: کاربران باید بتوانند تسکهای جدیدی اضافه کنند.
-
ویرایش تسک: کاربران باید بتوانند تسکهای خود را ویرایش کنند.
-
حذف تسک: کاربران باید بتوانند تسکهای خود را حذف کنند.
گام اول: انتخاب مقیاس
تیم تصمیم می‌گیرد از دنباله فیبوناچی برای تخمین استفاده کند. این دنباله به آنها کمک میکند تا با توجه به میزان تلاش، پیچیدگی و ریسک، مقادیر را مشخص کنند.
گام دوم: تشکیل جلسه پوکر برنامهریزی
تیم برای هر داستان کاربر جلسه‌ای تشکیل می‌دهد. هر عضو تیم یک کارت با عددی از دنباله فیبوناچی انتخاب میکند.
مثال: تخمین داستان کاربر «ثبت‌نام کاربر»
-
توضیح داستان کاربر:
-
توسعه‌دهنده فرانت‌اند توضیح می‌دهد که باید فرم ثبت‌نام طراحی و پیاده‌سازی شود.
-
توسعه‌دهندگان بک‌اند بیان میکنند که باید یک API برای ثبت‌نام ایجاد شود و داده‌ها در دیتابیس ذخیره شود.
-
طراح UI/UX طراحی فرم را بررسی میکند.
-
انتخاب کارت‌ها:
-
توسعه‌دهنده ارشد: 5
-
توسعه‌دهنده بک‌اند اول: 5
-
توسعه‌دهنده بک‌اند دوم: 8 (به دلیل نگرانی درباره پیچیدگی دیتابیس)
-
توسعه‌دهنده فرانت‌اند: 5
-
طراح UI/UX: 3
-
بحث و توافق:
-
پس از بحث، توافق میشود که استوری پوینت 5 برای این داستان مناسب است، زیرا پیچیدگی دیتابیس چندان زیاد نیست.
گام سوم: تکرار برای سایر داستان‌ها
همین فرایند برای سایر داستان‌های کاربر تکرار میشود. نتیجه نهایی بهصورت زیر است:
-
ثبت‌نام کاربر: 5 استوری پوینت
-
ورود کاربر: 5 استوری پوینت
-
افزودن تسک: 8 استوری پوینت
-
ویرایش تسک: 3 استوری پوینت
-
حذف تسک: 2 استوری پوینت
گام چهارم: استفاده از تخمینها در برنامهریزی اسپرینت
اگر «سرعت / Velocity» تیم 20 استوری پوینت در هر اسپرینت باشد، این تیم میتواند در یک اسپرینت موارد زیر را انجام دهد:
-
ثبت‌نام کاربر (5)
-
ورود کاربر (5)
-
افزودن وظیفه (8)
در انتهای اسپرینت، تیم نتایج را بررسی کرده و تخمین‌های خود را برای بهبود در اسپرینت بعدی اصلاح میکند.
یک اتفاق عجیب
در مقاله بازبینی استوری پوینتها نوشته ران جفریس، او به تاریخچه استفاده از استوری پوینتها در روش‌های چابک می‌پردازد و بیان میکند که اگرچه خود او این مفهوم را ابداع کرده است؛ ولی اکنون از این بابت متأسف است.
جفریس توضیح می‌دهد که در روش XP، ابتدا داستان‌ها بر اساس زمان تخمین زده می‌شدند و سپس به «روزهای ایده‌آل / Ideal Days» تغییر یافتند که در نهایت به «استوری پوینتها» تبدیل شدند.
او معتقد است که استفاده از استوری پوینتها برای پیش‌بینی زمانِ اتمام کار، ایده ضعیفی است و پیگیری مقایسه تخمینها با واقعیت را بیهوده می‌داند. همچنین، جفریس مقایسه تیمها بر اساس کیفیت تخمینها یا Velocity را مضر می‌داند و پیشنهاد میکند بهجای تمرکز بر تخمینها، بر ارائه سریع ارزش واقعی تمرکز شود.
بااین‌حال هنوز بسیاری از تیمها از این روش استفاده میکنند و به‌خوبی کارهای خود را مدیریت میکنند.
در نهایت
استوری پوینتها به‌عنوان یک ابزار مهم در روش‌های چابک، به تیمها کمک میکنند تا تلاش موردنیاز برای تکمیل تسکها را تخمین بزنند و فرایند برنامهریزی خود را بهبود دهند. با استفاده از روش‌هایی مانند دنباله فیبوناچی و جلسات پوکر برنامهریزی، تیمها می‌توانند ارزش نسبی وظایف را ارزیابی کرده و بر تحویل مداوم ارزش تمرکز کنند.
بااین‌حال، همان‌طور که رون جفریس اشاره میکند، نباید هدف از Story Point به پیش‌بینی زمان محدود شود، بلکه باید به‌عنوان ابزاری برای افزایش همکاری تیمی و مدیریت بهتر کارها مورداستفاده قرار گیرد.
|
«تفکر چابک فقط یک متدولوژی نیست، یک نگاه متفاوت به کار تیمی و حل مسئله است. در اجیلیتی، آموزش اجایل با رویکردی عملی، تدریجی و متناسب با فضای کاری تیمهای ایرانی طراحی شده است.»
|