اسکرام: چطور باگ‌ها را طی اسپرینت مدیریت کنیم

تیم‌های اسکرام در زمینه‌ی مدیریت باگ‌ها یا درست‌تر بگم Defect Management* به چند دلیل دست و پا میزنن: وقتی یه عیب کشف میشه، آیا باید تو بک لاگ اسپرینت قرار بگیره؟ اگه آره، پس انحرافی که به burndown میده و هدف اسپرینت رو تحت تاثیر قرار میده چی کار کنیم؟ اگه به بک‌لاگ محصول اضافه‌ش کنیم، مساله‌ی تاخیر در رفع مشکلات مهم رو چیکار کنیم؟

یادآوری:
«لازمه قبل از اینکه ادامه‌ی مطلب رو بخونین یادآوری کنم که رسیدن به موقع به هدف اسپرینت، مهمترین چیزیه که تیم اسکرام باید تمام مدت در نظر داشته باشه و روش تمرکز کنه. هدف اسپرینت مثل فانوس دریاییه.»

بیشتر مقدمه نمی‌چینم و مستقیم میرم سراغ راهکار و همزمان مشکلاتی که باهاش درگیر هستیم رو مرور میکنم. اگه بخوایم مساله رو ساده کنیم شاید بهتره اول سوال رو درست مشخص کنیم. سوال رو میشه اینطوری طرح کرد:

• وقتی یه باگ کشف میشه، چه کار کنیم که برنامه‌ به هم نریزه و هدف اسپرینت به خطر نیوفته؟
• یا نحوه‌ی صحیح مواجهه با عیوب نرم‌افزاری در پروسه‌ی دلیوری چیه؟

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

در مرحله اول،
کافیه مساله رو بر اساس «زمان کشف باگ» طبقه بندی کنیم. در واقع باید دو تا سوال بپرسیم که با توجه به اصول اسکرام، جوابها واضح به نظر میان پس وقتی با عیبی در نرم‌افزار مواجه شدیم، اینجوری شروع می‌کنیم:

۱- در اسپرینت جاری کشف شده؟

اگه باگ «طی اسپرینت» گزارش بشه، پس اون باگ باید در بک‌لاگِ اسپرینت قرار بگیره، یعنی ذیل همون استوری یا تسکی که بهش مربوطه یه ساب تسک ایجاد میکنیم یا باگش رو لینک میکنیم به تسک/استوریش (دومی رو برای باگ های کم اهمیت ترجیح میدم ولی در این مقاله وارد توضیح workflow و ابزار نشیم بهتره)

۲- از اسپرینت قبلی کشف شده؟

در واقع اگر از Product Increment یا همون ورژن خروجی اسپرینت قبلی کشف/گزارش شده، این میشه یه PBI و در بک‌لاگ محصول قرار میگیره؛ پس قرار نیست توی این اسپرینت بهش بپردازیم مگر اینکه شدت و اهمیت باگ، تاثیر خاصی روی محصول داشته.

خب حل شد که؟ مطلبو ببندیم و خدافظ :))

نه! همه‌ی باگ‌ها شرایط یکسانی ندارن که به این راحتی بشه در موردشون تصمیم گرفت! تیم و محصول و بیزنس هم همیشه در وضعیت یکسانی نیستن! داریم در مورد یه سیستم و پروسه‌ی پویا صحبت می‌کنیم، چرخ‌دنده‌ها و هدف و سایر ارزش‌ها. اون دو راه حل رو فعلا داشته باشین بعنوان شالوده‌ی ناقصِ راهکار، تا به بقیه‌ش برسیم.

میشه گفت همه‌ی باگها که اینقدر قابل توجه نیستن که براشون PBI ایجاد کنیم و گاهی دولوپر میتونه بعنوان بخشی از کارهای همین اسپرینت فیکسشون کنه. درسته؟ یا بعضی وقتا باگ از نوعیه که قرار نیست چون لزوما حین تستِ تسک/استوری کشف شده، حتما همون اسپرینت رفع بشه، مخصوصا وقتی در مورد رفتار مد نظر محصول توافق نظر نداریم که خودش یکی از شرایطیه که در ادامه شرح میدم.

پس مرحله‌ی دوم،
یه روش تشخیصی دیگه وجود داره که میتونه راهنمای تکمیلی مدیریت باگ ما باشه، یعنی پرسش‌های بیشتر برای تمیز دادن بیشتر باگهای نوع اول.

۳- آیا فیچر «طبقِ طراحی کار نمیکنه؟»

نمونه‌ای از یه باگ کلاسیکه دیگه. مثلا «وقتی روی این دکمه میزنم، اتفاقی نمیوفته»

یا

۴- آیا فیچر «اونطور که باید کار کنه طراحی نشده؟»

یعنی در مورد عملکردش، دیدگاه متفاوتی در تیم وجود داره؟
مثلا: «انتظار دارم رفتار متفاوتی ببینم، نه اونی که در استوری دستور داده شده»

پس این‌بار هم، در واقع با نگاه سیستمی مساله رو با پرسش های بیشتری باز می‌کنیم. الان خروجی روش اول رو اینجوری زیر سوال می‌بریم که:

گیریم یه باگ کلاسیک که از اسپرینت قبلی هنوز در محصول وجود داره و اصلا ممکنه دردسر ساز هم بشه، همچین باگی باید همین حالا فیکس بشه؟ پس هدف این اسپرینت چی؟ یا متعاقبا، فیچری که طبق طراحی هم کار می‌کنه، معنیش این نیست که کارکرد یا رفتار مطلوب رو داره، پس ازش بگذریم و درگیرش نشیم؟

داره پیچیده میشه؟ نگران نباشید. الان با رسم یه ماتریکس ۲×۲ راهکار تکمیل میشه و در ادامه تمام وضعیت‌هارو شرح میدم.

１- طبقِ طراحی کار نمیکنه و طی اسپرینت جاری کشف شده

این مدل باگها معمولا طی فرایند تست اتومات یا دستی که روی استوریِ انجام شده، کشف میشن. در واقع مربوطن به پیاده‌سازی یه استوری/تسک. مثلا داریم نرم‌افزار گرافیکی رو توسعه میدیم و به این عیب میرسیم:

«وقتی روی دکمه‌ی shape میزنم و چند ضلعی رو انتخاب میکنم با n تعداد ضلع، چندضلعی با n+1 ضلع روی بوم رسم میشه.»

آنچه باید کرد:

• آیا باگ پیش پا افتاده‌س؟ با ایجاد تسک زحمت اضافه درست نکنین؛ صرفا بعنوان بخشی از کار در حال انجام فیکسش می‌کنیم. اگه توسط هرکی به جز دولوپر کشف میشه، مثلا رو تسکش کامنت گذاشته بشه و و تسک برگرده به بک‌لاگ اسپرینت
• اگه رفع این باگ مشکل بود، مثلا در حدی که می‌تونست پیشرفت تیم در راستای دستیابی به هدف اسپرینت رو کند بکنه، پس یک تسک/ساب‌تسک مرتبط با استوری ایجاد کنید تا برای تیم واضح باشه که این میتونه روی پیشرفت تاثیر بذاره.
• در هر صورت مشکل رو در جلسه روزانه اسکرام مطرح کنید تا همه از وجود مشکل یا از پیشرفت در راستای فیکس کردنش مطلع بشن؛ حالا چه روی پیشرفت دستیابی به هدف اسپرینت تاثیر بذاره چه نذاره.
  

۲- اونطور که باید کار کنه طراحی نشده و طی اسپرینت جاری کشف شده

این نوع از باگ وقتی رخ میده که محصول اونطوری که انتظار میرفته کار میکنه، یعنی دقیقا طبق طراحی و ملاک‌های پذیرش (Acceptance Criteria) که تعریف شده کار میکنه، ولی با سایر رفتارهای محصول ناسازگار یا ناهمگونه، استفاده‌ش دشواره یا اصلا به هر دلیلی سَمبَل شده! (مثلا همه‌ی جوانب در طراحی دیده نشده)

مثلا هنوز داریم همون نرم‌افزار گرافیکی رو توسعه میدیم و عیب اینه:

«وقتی روی دکمه‌ی شکل (فرضا چند ضلعی) دوبار کلیک میکنم، یه properties box باید نمایش داده بشه، مثل وقتی که روی شکل دایره دوبار کلیک میکنم.»

آنچه باید کرد:

• وقتی کسی چنین باگی گزارش می‌کنه، باید در اسرع وقت به مالک محصول تیم گزارش بدین. منتظر جلسه روزانه نشید!
• اگه مالک محصول دلیل خوبی داشت که محصول همونطور رفتار میکنه که باید بکنه، بدترین چیز اینه که تیم بدون اینکه بپرسه تغییر ایجاد کنه. پس سرخود تغییر ندین!
• اگه رفتار محصول واقعا قابل قبول نیست، مالک محصول باید در مورد اینکه تغییر دادنش باعث به خطر افتادن هدف اسپرینت میشه همکاری کنه. مالک محصول و تیم توسعه لازمه اسکوپ آیتم رو مجددا تنظیم کنن و تغییر طراحی رو وارد آیتم کنن وگرنه ولش کنن و منتظر بازخورد در جلسه Sprint Review باشن.
  

۳- اونطور که باید کار کنه طراحی نشده و از اسپرینت قبلی کشف شده

چنین کاستی‌هایی لزوما باگ نیستن و دولوپرها معمولا اعتراض میکنن و میگن «من دقیقا همونی رو انجام دادم که گفته شده بود!»

مثال، توسعه‌ی فیچری از نرم‌افزار گرافیکی مذکور:

«وقتی طراحی رو ذخیره می‌کنم، تصویر بندانشتی (Thumbnail) آپدیت میشه تا لایه‌ی بالایی رو نمایش بده، در حالیکه باید همه‌ی لایه‌‌های قابل مشاهده رو نمایش بده.»

از منظر مشتری، رفتارِ محصولی که توقعاتش رو برآورده نکنه باگ محسوب میشه. دیگه مهم نیست اگه از منظر تیم توسعه محصول دقیقا همونطوری کار کنه که طراحی شده. بعضی وقتا باگ از بیرون تیم گزارش میشه – مثلا از سمت مشتریایی که دارن از نسخه‌ی عرضه شده استفاده می‌کنن – ولی این گزارشها میتونن هم از سمت تیم QA باشن که بعنوان مشتری فکر میکنن و صدای مشتری هستن.

آنچه باید کرد:

• در چنین شرایطی باید یک PBI ایجاد کرد و مالک محصول باید ارزیابی کنه و تصمیم بگیره که محصول لازمه تغییر بکنه یا نه.
• اگه PBI تایید بشه، مالک محصول باید تصمیم بگیره این تغییر چقدر اهمیت داره و کجای ترتیب بک لاگ محصول قرار بگیره.
  

۴- طبقِ طراحی کار نمیکنه و از اسپرینت قبلی کشف شده

این ربع چهارم ماتریکس بیانگر باگ‌های بی‌ چون و چراست: چیزی که طبق طراحی پیاده نشده و در increment جاری کشف شده یا حتی ممکنه ریلیز شده باشه.

مثلا هنوزم روی همون نرم افزار گرافیکی کار میکنیم و این عیب گزارش میشه:

«وقتی رنگ یک شکل رو تغییر میدم، تغییر روی بوم اعمال نمیشه مگر اینکه فایل رو ذخیر کنم و دوباره باز کنم.»

وقتی چنین باگی گزارش میشه بعضی از تیم‌ها وسوسه میشن مستقیم شیرجه بزنن توش، سریع فیکسش کنن و با ریلیز بعدی یا hotfix مرخصش کنن. اما به قول معروف، اینکه تو طبیعت وِله که دلیل نمیشه مال تو باشه! یعنی کار کردن رو اینها لزوما منطقی نیست.

آنچه باید کرد:

• چنین باگ‌هایی باید در بک‌لاگ محصول اضافه بشن.
• مالک محصول اهمیت و اولویتش رو مشخص کنه.

ممکنه استثنائا باگ مربوط بشه به تسک/استوری که در اسپرینت جاری داره کار میشه، ولی رفعش هم سخت نیست. به عبارت دیگه میتونه بدون به خطر انداختن هدف اسپرینت فیکس بشه؛ پس فقط در اینصورت، بعد از صحبت با مالک محصول و با بسط دادن اسکوپ آیتم مربوطه (تسک/استوری) میتونه وارد اسپرینت و فیکس بشه.

خلاصه که همه‌ش مربوط به ارتباطات صحیحه

ارتباط بین مالک محصول و تیم توسعه کلید اصلی در مدیریت عیبهای نرم‌افزاریه. هیچ یک از وضعیت‌های شرح داده شده در ماتریکس، به تنهایی وحی منزل نیستن! حتی اون عیبی که «طبقِ طراحی کار نمیکنه و طی اسپرینت جاری کشف شده» هم پتانسیل داره که نادیده گرفته بشه (اگه منطقی باشه که بعنوان بدهی فنی برای کوتاه مدت تلقی بشه) و منتقل بشه به بک لاگ محصول. نکته اینجاست که با درک اینکه عیبها چی هستن، از کجا میان و چطور میشه اونها رو برطرف کرد، می تونیم در مسیر هدف اسپرینت بمونیم.

* این defect در معنوی لغوی میشه «عیب، کاستی، کمبود یا نقص»
اگه بخوایم جامع صحبت کنیم بهتره از این استفاده کنیم نه باگ.Defect در صنعت نرم‌افزار برای اشاره به اشکالات نرم‌افزاری استفاده میشه مثل Error، اشتباه محاسباتی، Crash، مسائلی که منجر به خطای کاربر یا نارضایتیش میشن (Interface Glitches). در واقع هر گونه مساله‌ای که باعث میشه محصول یا فیچر، عملکردی که ازش انتظار میرفته، نداشته باشه. از اونجایی که به طور عام، مصطلح شده که Bug صداش میکنن، من بیشتر جاهای مقاله و در عنوان از همون باگ استفاده کردم.

لطفا اگه هرجا رو متوجه نشدین یا گنگ بود، در کامنت بهم بگین تا ضمن توضیح، خود مقاله رو هم بهبود بدم.

ارادتمند،
سعید سپهر