برای یک توسعه دهنده بعد از مراحل سخت توسعه دیگر همه چیز به رویا نزدیک میشود تا اینکه اولین باگ توسط مدیر محصول کشف میشود.
همیشه پیش نرفتن هر چیزی مطابق آنچه انتظار داریم کمی افسرده کننده است.
این مشکل نباید پیش می آمد؟ آیا روش من درست نبوده؟ من ایده آلیست ام؟ من چه هستم؟ آه…
در مانیفست توسعه چابک نرم افزار(agile) داریم که "توسعه چابک در مورد این نیست که وانمود کند جهان پیرامون شما بی عیب و تمام عیار است، بلکه در مورد سازگاری با واقعیت و بازگو کردن آن برای بهبود فرایند هایتان و انعطاف پذیری است. پس وقتی مشکلات بروز میکنند شما قادر خواهید بود با آنها مواجه شوید".
پس از دانستن این تعریف میتوانیم دیگر افسرده نباشیم اما مشکلات ناشی از بروز باگ در محصول به دست مشتری رسیده همچنان وجود خواهند داشت. باید همه آنها را حل کنیم؟ چگونه؟
باگ ها اغلب بر اساس تاثیر مخربی که بر محصول ما میگذارند قابل شناسایی هستند.
اولین نوع آنها را میتوانیم کمترین تاثیر بدانیم، بعد از رخ دادن چنین باگی شما میتوانید به جایی که در قبل از آن بودید برگردید و مشکل حل خواهد شد.
ابزارهای توزیع محصول (production deployment systems) مثل گیت به شما این امکان را میدهد.
دومین نوع را میتوان به باگ های اطلاق کرد که برای کشف نیاز به عمیق شدن بیشتر در داده های بدست آمده از سیستم خود دارید زیر ا که بیشتر در ذخیره سازی اطلاعات رخ خواهد داد و اغلب با بازیابی داده ها قابل برطرف شدن است.
این نوع باگ ها معمولا با در نظر گرفتن نوع آنها درمراحل توسعه و تست و همچنین عمیق تر دنبال کردن داده ها پس از ارائه سیستم قابل ردیابی است.
این نوع باگ ها با توجه به اینکه در ظاهر قابل مشاهده نیستند اما بسیاری از آنها رو اغلب میتونید در خواب ببینید که بهش میگن اشراق!
مثلا در خواب ببینید مقدار تخفیف که محاسبه کردید رو در فیلد تخفیف سفارش ذخیره نکردید و الان تبدیل به یک هیولا شده و دنبال شما میگرده.
باگ هاي روشن و بيرون زده نوع سوم هستند که تاثیرات آنها بر سیستم بسیار حیاتی هستند و بسیار لازم است تا در اسپرینت جاری رفع شود و امکان صبر کردن برای رفع مشکل تا اسپرینت بعدی نخواهد بود.
باید توجه داشت، همان قدر که برای ادامه عملکرد سیستم نیازمند رفع مشکل هستیم اما وارد کردن سناریوی جدید در میانه کار اصلا ایده خوبی نیست.
برای محدود کردن این تغییرات مدیر اسکرام با مدیر محصول بدون تیم توسعه وارد مذاکره میشوند تا راه حل را برای توسعه تدوین کنند.
اما گزینه آخر و کابوس وار تأثیرات هسته ای و مهلک است که راه گریز از آن فراتر از تیم توسعه است و ناچار خواهید بود که متاسفانه ادامه روند را متوقف کنید و روندهای خود را بازبینی کنید، احتمالا در نقشه نحوه عملکرد سیستم تغییر بوجود خواهد آمد.
اما چه وقت میتوانیم به مسئله بوجود آمده باگ بگوییم و چه وقت نمیتوانیم؟
باگ قطعا پس از شناسایی سناریو کاربری و شبیه سازی آن رخ میدهد و در اینصورت است که میتوانید مسئله موجود را باگ بخوانید.
باید ارائه محصول به تایید مدیر محصول رسیده باشد تا بتوان مشکلات پیش آمده پس از انتشار آنرا باگ نامید چرا که در بسیاری از اوقات توسعه دهندگان با وجود ایجاد محیط تست برای توسعه نرم افزار دچار اشتباه میشوند زیرا که آنها تنها پنداشت خود را از عملکرد صحیح سیستم دارند.
باگ ها باید توسط مشتری یا کاربر نهایی سیستم گزارش و یا شناسایی شوند.
و اما ما محصولی را باگی مینامیم که که کاربران آن تجربه کاربری خوبی ندارند.
و نکته آخر در شناسایی باگ اگر هنوز مردد هستید این است که باگ ها اصولا در پایان ساعات کاری یا روزهای تعطیل وقتی در حال تفریح هستید رخ میدهند :)
با توجه به تعاریف گفته شده از باگ ها مطمئنا با موارد دیگری مواجه شده اید که نمیتوانیم آنها را باگ بنامیم. باقی موارد خارج از تعاریف گفته شده را با مفهوم دیگری معرفی میکنیم به نام مسئله (issue). و به مشکلاتی گفته میشود که تیم توسعه در طول یک اسپرینت با آن مواجه میشود و الزاما نباید در لیست بکلاگ باشند.
شاید بتوان گفت در بسیاری مواقع یافتن و رفع باگ کافی نیست، میتوان گفت برای پوشش بیشتر و جلوگیری از ایجاد تجربه کاربری بد برای مشتری لایه جدیدی را به تیم اضافه میکنند تا مسئله یابی را انجام دهند. هدف این است که زودتر از مشتری مشکلات را بیابید و رفع نمایید و با استمرار بر این روش جنبه های پنهان محصول خود را زیر نظر بگیرید. مسئله یابی در واقع کار بر روی چیزهای درست به جای کار بر روی چیزهای نادرست است و در نهایت داشتن مشتری و البته مدیر محصول! خوشحال تر.
با این روش میتوانید نیروهای بدون دانش فنی خود را آموزش دهید تا اطلاعات بدست آمده از مشکلات محصول خود را طبقه بندی کنند:
ذخیره سازی: چه چیزی باید گزارش شود؟چه زمانی و چه کسی تصمیم میگیرد؟
پاسخگویی: به چه کسی گفته شود؟ آنها چه پاسخی داده اند؟
اولویت: چه چیز هایی اهمیت بالاتری دارند؟
حل مسئله: راه حل چه بوده؟ چگونه حل شده است؟
بازبینی: آیا به درستی کار میکند؟
با دانستن اینکه فقط یک درصد مشتریان باگ ها را گزارش میدهند، پیداست که شما باید فرآیندی برای پیدا کردن و حل مشکلات سیستم بدون تاثیر گذاری بر روند توسعه داشته باشید.
حداقل دو روش کارامد برای رفع باگ ها با رعایت اولویت اهمیت آنها بر اساس تاثیری که بر عملکرد محصول میگذارد میتوان معرفی کرد:
اولین روش اینکه هات فیکس ها را در بالای لیست بک لاگ ها قرار دهیم و تیم توسعه به سرعت آنها را رفع کند.
دومین روش هم اینکه هات فیکس ها را در لیست جداگانه ای قرار دهیم و تیم توسعه یا بخشی از آن قبل از توسعه امکانات جدید، ابتدا به هات فیکس ها بپردازد.
در هر دو روش ریسک انجام نشدن وظایف جدید به دلیل مشغول بودن تیم توسعه به رفع باگ ها وجود دارد اما به نظر میاد روش اول شفاف تر است چرا که مشخص نیست چقدر رفع باگ ها از تیم زمان خواهد برد...
