اول بگم که چیزی که می‌گم اصلاً دنبال بیان تئوری‌ها و نقدشون یا نظر جدید نیستم. فقط تجربه‌ی خودم هستش که به اشتراک می‌ذارم.
تو این چند سالی که تو حوزه‌ی اجایل مشغول به کار هستم، حالا چه به عنوان اسکرام مستر یا چه به عنوان اجایل کوچ یا حتی دولوپر جونیور، همیشه مسئله‌ای که به صورت جدی مطرح بوده، نحوه‌ی استیمیت دادن تو جلسات پلنینگ هستش. این دعوا که بچه‌های دولوپر با ساعت بهتر کنار میان یا نه، اگه می‌خوایم اجایل کار کنیم باید استوری پوینت بدیم، یا اگه استوری پوینت رو حتی بچه‌ها فهمیدن باز هم همون ساعت معادلش تو ذهنشون میاد، همیشه برای منم چلنج بوده. اما چیزی که تو طی این سال‌ها یاد گرفتم رو سعی می‌کنم تا حدودی ساختارمندتر اینجا بیان کنم، شاید به درد کسی بخوره.
مسئله‌ی اصلی: مواجه شدن با آنچه توافق می‌کنیم
به نظر من تو این مسئله‌ی خاص کلاً هدف گم شده. چه استوری پوینت بدیم به عنوان تخمین، چه نفر-ساعتی بریم جلو، در نهایت ما به دنبال بهبود تو فرایند دولوپ و ارائه‌ی محصول به صورت چابک هستیم. پس در هر صورت باید ببینیم چه چیزی گرفتیم و چه چیزی داریم پس می‌دیم. می‌خوایم بازخورد بگیریم که فرایندهامونو بهبود بدیم؛ مفهوم اجایل هم همینه دیگه.
مسئله‌ی مهم اینه که هر آنچه رو به عنوان تخمین در نظر می‌گیریم، بعداً به صورت شفاف باهاش مواجه بشیم.
اصلاً یکی از کارهای مهم اسکرام مستر همین مواجه کردن تیم اسکرام با این مسائل هستش.
اما طرح مشکل
دولوپرها دوست دارن که روی تسک‌های ریز به نفر-ساعت تخمین بدن، و خب صد البته مشخصه که اگه بخوایم به صورت کلی روی استوری تخمین بدن، هم دچار خطا می‌شن هم تمایلی به این کار ندارن. از طرف دیگه، شکستن کارها به ساب‌تسک‌های ریز هم کار آسونی نیست و معمولاً کار زمان‌بری هستش. همچنین استوری پوینت دادن و درک مفهومش برای تیم کار آسونی نیست.
من خیلی جاها، به درست یا غلط، دیدم که نهایت مثالی که برای استوری پوینت زده می‌شه اینه که می‌گن: «خب ببین، مثلاً ۳ استوری پوینت یعنی ۸ ساعت کاری یا یک روز» و بعد طرف می‌گه: «اِ، خب باشه، پس این استوری ۳ تا پوینت ردیفه». در صورتی که این نیست.
از دوستی شنیدم که می‌گفت ما استوری پوینت می‌گیریم که تیم فنی تحت فشار زمان نباشه و تو اسپرینت راحت باشه. و من باز هم می‌گم نه، معنی نداره؛ توجیه خوبی هم نیست. ما بالاخره تو اسکرام داریم تایم‌باکس می‌ریم جلو، بحث ایتریشن‌ها مطرحه، متمرکز کار کردن و زمان برامون مهم هستش. پس بالاخره چی‌کار باید بکنیم؟
تجربه‌ی من و راه‌حلی که استفاده کردم
من معمولاً هر جا شروع کردم با تیم‌ها کار کردن، برای استیمیت دادن سعی کردم استوری‌ها رو، بعد از اینکه مالک محصول توضیح کامل داد، بچه‌های فنی بشکوننشون و روی ساب‌تسک‌ها با پوکر استیمیت بدن، و تا جایی که می‌شه تسک‌ها به کمتر از یک روز کاری شکسته بشن.
خب حالا تو جیرا اگه دقت کرده باشین، مجموع استیمیت‌های ساب‌تسک‌ها رو روی تایم‌ترکینگ استوری نشون می‌ده، و حتی اگه روی خود استوری هم استیمیت داده باشین با اون جمع می‌کنه؛ ولی باز هم استیمیت ساب‌تسک‌ها رو به عنوان استیمیت استوری در نظر نمی‌گیره. و تا جایی که من می‌دونم، جیرا هم اعتقاد داره اگه می‌خوای استیمیت بدی، روی استوری استیمیت بده؛ این مسخره‌بازی‌ها چیه!
من چند تا اسپرینت به همین منوال می‌رم جلو و با برن‌داون چارت و گزارش‌های دیگه سعی می‌کنم لاگ بچه‌ها رو با استیمیتشون هم به نمایش بذارم و با هر چیزی که استیمیت دادن مواجهشون می‌کنم، تا تفاوت لاگ‌هاشون رو با استیمیت‌هاشون ببینن و به سمت بهبود این تفاوت بریم.
اما کم‌کم جلسات پری‌پلن با مدیر فنی (CTO) و مالک محصول می‌ذارم، و برای استوری‌ها، بر اساس پیچیدگیشون و به صورت مقایسه‌ای، از مدیر فنی می‌خوام به استوری‌ها استوری پوینت بده و معمولاً روی استوری‌ها ثبتش می‌کنم. می‌دونین که تو جیرا می‌تونیم هم فیلد استوری پوینت بذاریم هم اوریجینال استیمیت.
بعد تو جلسات پلنینگ از مدیر فنی می‌خواستم استوری‌ها رو با هم از لحاظ پیچیدگی مقایسه کنه و پوینتی که به هر کدوم داده رو بگه. ولی همچنان از تیم دولوپ، با همون تکنیک پوکر، می‌خواستم که روی ساب‌تسک‌ها بر اساس نفر-ساعت استیمیت بدن، و این کار رو تا چند تا اسپرینت بعدی ادامه می‌دادم. دقیقاً با همون نمودارها و گزارش‌ها، این بار یه معیار مقایسه‌ی دیگه هم به تیم نشون می‌دادم، و اونم پوینت‌هایی بود که داده شده بود؛ و فقط به صورت ویژوال ازشون می‌خواستم ببینن که ارتباط معناداری بین مجموع ساعت‌هایی که تخمین زدن و پوینت‌هایی که داده شده هست یا نه.
و اینجاست که تیم داره یاد می‌گیره که مفهومی به اسم استوری پوینت چه‌جوری و بر اساس پیچیدگی داره شکل می‌گیره، و می‌شه روش حساب کرد و روی استوری‌ها هم به صورت پوینتی استیمیت داد.
پس بعد از چند اسپرینت، می‌تونیم کم‌کم روی استوری‌ها بدون هیچ ترس و واهمه‌ای پوینت بدیم و با مقایسه‌ی استوری‌ها و تجربه‌ی قبلی، به صورت اجایل استیمیشن داشته باشیم.
همه‌ی این مواردی که گفتم به خیلی از مسائل و کانتکست‌ها، مثل بلوغ تیم یا بلوغ محصول، بستگی داره. اما چیزی که من یاد گرفتم و ازش واقعاً نتیجه گرفتم این هستش.
خوشحال می‌شم نظراتتون رو در این مورد بشنوم.
