“چطور میشه آیتم‌های بک‌لاگ اسپرینت رو بهتر تخمین زد؟”
“جداً کلافه شدیم! اول اسپرینت کلی کار می‌ریزیم تو برنامه، اما هنوز به وسط نرسیده یا آخر اسپرینت، مجبور میشیم کلی از اون‌ها رو از اسپرینت حذف کنیم.”

من با تیم‌های زیادی کار کردم و تقریباً همه آنها دنبال یک جور عصای جادویی هستن که باعث بشود برنامه‌های اسپرینت‌ را دقیقِ دقیق برنامه ریزی بکنند. همین اول بگویم: چنین چیزی وجود نداره! اما چیزی که وجود دارد، روش‌های هوشمندانه‌تری برای روبرو شدن با این عدم قطعیت‌هاست.

امروز می‌خواهم دو ایده کاربردی و امتحان پس داده را با شما در میان بگذارم که اسم آن “چارچوب برنامه‌ریزی واقع‌بینانه” (Factful Planning Framework) گذاشتم.

سوءتفاهم بزرگ: ما اصل “مسئله” رو در مورد مسائل پیچیده فراموش می‌کنیم

قضیه اینجاست: اسکرام یک چارچوب برای مسائل پیچیده و انطباقی (complex adaptive problems) است یعنی چیزهایی که ذاتاً آشفته، غیرقابل پیش‌بینی و دائماً در حال تغییر هستد. همه روی کاغذ این‌ را قبول دارند. اما در عمل چی؟ خیلی از تیم‌ها (و مدیران!) با اسکرام مثل یه ابزار مدیریت پروژه سنتی برخورد می‌کنند و شروع می‌کنیم به نادیده گرفتن بزرگترین فیل در اتاق: عدم قطعیت (uncertainty).

در دنیای پیچیده نرم‌افزار، عدم قطعیت یک باگ نیست؛ یک ویژگی جدانشدنی این دنیاست و نمی‌توانید آن را نادیده‌ بگیرید. خب، پس چطور می‌توانیم در این دنیای پر از ابهام، برنامه‌ریزی و تخمین داشته باشیم؟

ماتریس ابهام (Uncertainty Matrix)

اول از همه، همه آیتم‌های بک‌لاگ از نظر میزان ابهام یکسان نیستند. بعضی‌ از آنها خیلی سرراست هستند، برخی دیگر کاملاً مبهم و ناشناخته هستند. ماتریس ابهام یک ابزار فوق‌العاده ساده‌ست که کمک می‌کند این موضوع را درست تشخیص بدهید.

این ماتریس دو چیز مهم را بررسی می‌کند:

۱. چه چیزی (WHAT): دقیقاً چه چیزی قرار هست بسازیم؟ نیازمندی‌ها چقدر شفاف و روشن است؟
۲. چگونگی (HOW): چطور قرار هست آن را بسازیم؟ مراحل فنی کار را می‌دانیم؟

یکی از آیتم‌های بک‌لاگ محصول (Product Backlog Item یا PBI) را انتخاب کنید:

برای بُعد “چه چیزی”:

• ۱ – کاملاً شفاف و واضح: دقیقاً می‌دونیم چی باید انجام بشه، همه جزئیات مشخص هست.
• ۲ – تا حد زیادی روشن، اما با ابهاماتی در جزئیات: کلیات کار دستمون هست، اما بعضی جزئیات هنوز مبهم هست یا نیاز به شفاف‌سازی دارد.
• ۳ – پر از علامت سوال بزرگ: هدف کلی خیلی گنگ هست، یا جزئیات اصلاً مشخص نیست.

و برای بُعد “چگونگی”:

• ۱ – مشابهش رو قبلاً انجام دادیم: دقیقاً می‌دونیم چطور باید پیاده‌سازیش کنیم؛ قبلاً کارهای مشابهی انجام دادیم.
• ۲ – تقریباً مطمئنیم، اما ممکنه به مشکل بخوریم: ایده کلی خوبی داریم، اما شاید چالش‌های فنی یا حوزه‌های جدیدی پیش بیاد.
• ۳ – ورود به حوزه ناشناخته: هیچ ایده روشنی نداریم که چطور باید این کار رو انجام بدیم؛ باید تحقیق کنیم یا چیزهای مختلفی رو آزمایش کنیم.

حالا به آیتم بک‌لاگتون یه امتیاز بدهید، مثلاً “۲-۳” (یعنی امتیاز ۲ برای “چه چیزی” و امتیاز ۳ برای “چگونگی”).

برنامه‌ریزی اسپرینت واقع‌بینانه: استفاده از ماتریس

یک جلسه برنامه‌ریزی اسپرینت را تصور کنید یک آیتم با اولویت خیلی بالا دارید، اما در ماتریس ابهام امتیاز “۳-۳” گرفته است. این آیتم فوق‌العاده مهم هست، اما یک ناشناخته تمام‌عیار نیز هست. خوب از تیم خواسته میشود که تخمینش بزنند.

تیم چطور می‌تواند برای چیزی که اینقدر نامشخص هست، یک تخمین معنی‌دار بدهد؟ اصلاً تخمینی که قرار هست اشتباه از آب دربیاد، چه ارزشی دارد؟ این بیشتر یک حدس هست تا تخمین.

اینجاست که ماتریس ابهام معجزه می‌کند. ما را مجبور می‌کند هدف اصلی اسکرام رو به یاد بیاریم: “رسیدگی به مسئله پیچیده.”

نکته کلیدی و متحول‌کننده برای برنامه‌ریزی اسپرینت:

• تعهد به پیاده‌سازی آیتم‌هایی که امتیاز ‘۳’ دارند (چه در ‘چه چیزی’ و چه در ‘چگونگی’) را در اسپرینت فعلی ندید.
• چرا؟ چون نمی‌توانید به طور قابل اتکایی آنها را تخمین بزنید. تعهد به انجام آنها، انتظارات نادرستی در ذی‌نفعان ایجاد می‌کند که (به حق) انتظار دارند این آیتم‌ها در پایان اسپرینت انجام شده باشن.

پس با آیتم‌های سطح ۳ ابهام چیکار کنیم؟

از خودتون بپرسید:
“در این اسپرینت چه کاری می‌توانیم انجام بدهیم تا دانشی ایجاد کرده و سطح ابهام این آیتم رو کاهش بدهیم؟”

با این سوال، تیم از تعهد کورکورانه به کارهای ناشناخته، به سمت تلاش فعال برای افزایش قطعیت حرکت می‌کند.

راهکارهایی برای کاهش ابهام در بُعد “چه چیزی” (ابهام سطح ۳ در “What”):

1. صحبت با مشتری: گاهی یک گفتگوی کوتاه، خیلی از موارد را روشن می‌کند.
2. ساخت MVF (حداقل ویژگی ارزشمند/آزمایشی – Minimum Viable Feature/Experiment): کوچکترین چیز ممکن را بسازید تا بازخورد واقعی بگیرید.
3. جلسات پالایش بک‌لاگ (Refinement/Grooming): زمان مشخصی را به شکستن آیتم‌ها، نوشتن معیارهای پذیرش (Acceptance Criteria) و بحث و گفتگو اختصاص بدهید.
4. اسپایک عملکردی (Functional Spike): (پایین‌تر در مورد اسپایک بیشتر توضیح میدم!)

من تیم‌هایی را دیدم که هیچ‌وقت با کاربران واقعی‌شون صحبت نمی‌کنند. گاهی فقط یک گفتگو می‌تواند سطح ابهام را از ‘۳’ به ‘۱’ کاهش بدهد. گاهی هم نیاز به ساخت یک نمونه اولیه دارید.

اسپایک (Spike) چی هست؟
اسپایک را مثل یه تسک تحقیقاتی در نظر بگیرید. هدف تولید یه ویژگی قابل تحویل نیست، بلکه کسب دانش هست. طراحی میشود تا به یه سوالی جواب بدهد یا ابهامی را برطرف کند.

• اسپایک عملکردی (Functional Spike): هدف آن شفاف‌سازی این هست که چه چیزی باید انجام بشود. مثال: “ساخت نمونه اولیه از طرح کلی داشبورد مدیریت دارایی‌ها برای اینکه ببینیم آیا با جریان کاری کاربر همخوانی داره یا نه.” یا، “آیا کاربر اصلاً به این دکمه اینجا نیاز دارد؟”

راهکارهایی برای کاهش ابهام در بُعد “چگونگی” (ابهام سطح ۳ در “How”):

1. اسپایک فنی (Technical Spike): بررسی می‌کند که چطور باید چیزی رو ساخت. مثال: “تست کنیم کدوم کتابخونه برای اسکن SNMP بهتره.” یا، “آیا معماری فعلی ما می‌تونه این نوع داده جدید رو پشتیبانی کنه؟”

این اسپایک‌ها برای بررسی راه‌حل‌ها و کاهش ابهام در “چگونگی” انجام کار هستن.

“چه چیزی” در مقابل “چگونگی” – اولویت با کدومه؟
اگه یک آیتم امتیاز “۳-۳” داره (یعنی هم در “چه چیزی” و هم در “چگونگی” مبهم هست)، اول سراغ “چه چیزی” بروید. چون “چگونگی” انجام کار، خیلی به نیازمندی‌های شفاف بستگی دارد. اول مشخص کنید چه چیزی قرار هست بسازید، بعد خیلی عمیق وارد این بشوید که چطور می‌خواهید آن را بسازید.

آیا این روش‌ها جلوی تغییر رو می‌گیرن؟
اصلاً اینطور نیست؛ ما نمی‌توانیم تغییر را نادیده بگیریم. سطح ابهام آیتم‌ها با گذشت زمان و بر اساس دانش جدیدی که از کسب‌وکار و تکنولوژی به دست میاوریم، تغییر میکند. این چارچوب فقط یک ابزار ساده‌ست تا واقعیت، یعنی “عدم قطعیت” رو به ما یادآوری کند. به جای اینکه کلی وقت برای یک برنامه “بی‌نقص” تلف کنید، انرژی را صرف ایجاد دانش در زمان مناسب کنید.

بازبینی اسپرینت (Sprint Review) واقع‌بینانه – برچسب “دمو برای چه کسی؟”

یکی دیگر از روش‌های ساده اما قدرتمند در برنامه‌ریزی واقع‌بینانه، اضافه کردن برچسب “دمو برای چه کسی؟” (Demo For) به آیتم‌های بک‌لاگ هست.

وقتی دارید برنامه‌ریزی می‌کنید، بپرسید: “در پایان این کار، نتیجه رو باید به طور مشخص به چه کسی نشون بدیم و بازخورد بگیریم؟”

• بعضی آیتم‌ها، مخصوصاً مواردی که “۱-۱” هستن (هم “چه چیزی” و هم “چگونگی” واضح و مشخص هست) و بیشتر فنی هستن، شاید فقط نیاز به تأیید مالک محصول (Product Owner) داشته باشند.
• اما آیتم‌هایی که ابهام بالاتری دارن، یا روی کاربران خاصی تأثیر می‌گذارند، نیاز به بازخورد از افراد درست و مرتبط دارند.

البته ننویسید “بچه‌های مارکتینگ”. دقیق باشید: “آقای رضایی، مدیر انبار، و خانم احمدی، کاربر نرم‌افزار انبار.”

چرا برچسب “دمو برای چه کسی؟” اینقدر مفید هست؟

1. بازخورد درست، از آدم درست: اگه یه ویژگی برای تیم فروش ساختید، باید از تیم فروش بازخورد بگیرید، نه از تیم مهندسی.
2. جلسات بازبینی (Review) کارآمدتر: وقت همه رو با دمو دادن تغییرات فنی جزئی، تلف نمیکنید. جلسات بازبینی متمرکز و ارزشمند نگه می شوند.
3. مشارکت فعال و به‌موقع ذی‌نفعان: می‌توانید این افراد مشخص را از قبل به جلسه دعوت کنید. آنها هم می‌توانند در تقویمشان علامت بزنند و آماده در جلسه حاضر شوند.
4. فراموش نکردن گرفتن بازخورد: این برچسب مثل یک یادآور داخلی عمل می‌کند تا گرفتن بازخورد از افرادی که نظر آنها واقعاً مهم هست را فراموش نکنید.

اگراین روشها را امتحان کردین دوست دارم نظرات شما رو هم بدانم که چقدر این شیوه برای شما مفید بوده است؟‌