در راهنمای اسکرام، «پالایش بک‌لاگ محصول یا Product Backlog Refinement» بدین‌صورت تعریف می‌شود:

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

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

در ادامه ۶ نکته ارایه می‌شود که می‌تواند به اثربخشی بیشتر تلاش‌ها در پالایش بک‌لاگ محصول منجر شود:

۱) اطمینان از مشارکت افراد درست

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

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

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

۲) تخصیص زمان مناسب

پالایش بک‌لاگ محصول یک رویداد اسکرام با چارچوب زمانی از پیش تعیین شده نیست. به بیان دیگر همانند خلق و ایجاد افزونه‌ای برای محصول، پالایش بک‌لاگ محصول نیز فعالیتی مستمر است. از همین‌ور لازم است پیش از برنامه‌ریزی هر اسپرینت، در اسپرینت‌های پیشین، زمان کافی برای پالایش بک‌لاگ محصول تخصیص داده شده باشد. زمانی که باید برای این‌کار تخصیص داده شود به وضعیت بک‌لاگ محصول بستگی دارد. در روزهای نخستین، احتمالا لازم باشد زمان قابل توجهی به پالایش بک‌لاگ محصول اختصاص داده شود. با شکل‌گرفتن بک‌لاگ محصول، مولفه‌های با اولویت بالا (بالای بک‌لاگ محصول)، دقیق‌‌تر و کوچک‌تر شده و جزییات بیشتری از آنها در دسترس خواهد بود (برای یک یا دو اسپرینت پیش‌رو و نه بیشتر از آن). این در حالی است که مولفه‌های بخش‌های میانی و پایینی کلی‌تر بوده، جزییات کم‌تری خواهند داشت. در این مرحله، توسعه‌دهندگان می‌توانند زمان کم‌تری را به پایش بک‌لاگ محصول تخصیص دهند. البته این زمان به صفر نخواهد رسید و معمولا در حدود ۱۰ تا ۱۵ درصد زمان اسپرینت را به خود اختصاص خواهد داد تا ضمن حفظ ساختار بک‌لاگ محصول، برای اسپرینت‌های بعدی همواره و به‌طور منظم آمادگی وجود داشته باشد.

) تکامل و تفصیل تدریجی (Progressively Elaborate)

هر یک از مولفه‌های بک‌لاگ محصول یا روایت‌های کاربری به صورت تدریجی و گام به گام پالایش می‌شوند و هر چه در بک‌لاگ محصول بالاتر می‌رویم، مولفه‌ها با جزییات بیشتر تعریف شده‌اند. به‌خاطر داشته‌باشید که بررسی و پالایش یک‌باره تمامی مولفه‌ها و تصور اتمام کار، دام و تله‌ای است که باید از آن اجتناب کرد. به‌جای نگرش یکباره به پالایش بک‌لاگ محصول، باید آن را در زمان مناسب (Just-in-Time)، به دفعات، با افزایش تدریجی جزییات و متناسب با اطلاعات جدیدی که به دست می‌آیند، انجام داد.

یک مولفه بک‌لاگ محصول ممکن است در ابتدا تنها یک عنوان باشد، با بالا رفتن آن در بک‌لاگ محصول (افزایش اولویت)، می‌توان در مورد جزییات زیر گفتگو و بررسی کرد:

  • چه‌کسی از ویژگی حاصل بهره‌مند خواهد شد؟
  • آن شخص چه نیازی دارد و چرا آن نیاز را دارد؟ و سپس آن‌را به صورت یک روایت کاربری نوشت.

همزمان با حرکت بیشتر روایت کاربری به سمت بالای بک‌لاگ (افزایش اولویت)، به‌طور معمول برای شفاف‌سازی بیشتر، معیارهای پذیرش به آن افزوده خواهد شد. با دستیابی به اطلاعات جدیدتر، برآورد، تخمین و اندازه‌گذاری انجام می‌شود و در صورت بزرگ یا پیچیده بودن روایت کاربری، احتمال تجزیه آن به مولفه‌های کوچک‌تر موضوعیت خواهد یافت. اگر تمامی این اقدام‌ها را تنها یک‌بار و در ابتدای کار و به‌طور کامل انجام دهیم (به‌جای پالایش تدریجی در هر اسپرینت به سراغ تعریف Big Upfront Requirements برویم)، احتمالا با اتلاف جدی منابع مواجه خواهیم شد چرا که ممکن است زمان صرف مولفه‌هایی شود که بعدها فاقد اولویت باشند یا کنار گذاشته شوند. این اتلاف در زمان مواجهه با ویژگی‌ها و الزامات با اولویت و اهمیت بیشتر موضوعیت بیشتر خواهد یافت. از همین‌رو همواره باید به‌خاطر داشت که پالایش بک‌لاگ محصول فعالیتی تدریجی و مستمر است و نه اقدامی یک‌باره!

۴) اندازه‌گذاری و تجزیه (Size & Split)

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

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

۵) تنظیم «تعریف آماده Definition of Ready»

«تعریف آماده یا آمادگی» می‌تواند ابزاری مفید باشد، مشروط بر آن‌که به عنوان یک راهنما مورد استفاده قرار گیرد و نه به عنوان یک مانع و الزام به‌گونه‌ای که بین توسعه و بک‌لاگ محصول حایل ایجاد کند (این مفهوم در ویرایش ۲۰۲۰ راهنمای چابک تصریح نشده‌است). تیم اسکرام، تعریف آمادگی را برای ایجاد درکی مشترک از نوع پالایش‌های مورد انتظار برای یک روایت کاربری پیش از ورود آن به بک‌لاگ اسپرینت تنظیم و تدوین می‌کند. این تعریف می‌تواند شامل راهنمایی‌هایی در مورد ارزش، اندازه، معیارهای پذیرش، مستندات پشتیبان، نمودارها و مانند آنهاست. نکته مهم آن است که از این تعریف به عنوان محرکی برای گفت‌وگو در جریان پالایش بک‌لاگ محصول استفاده می‌شود و نه به عنوان چک‌لیستی لازم‌الاجرا برای عبور از یک درگاه (Gate or Gateway).

) پرداختن و آدرس‌دهی به تغییرات

حتما درباره به‌روز رسانی‌های انجام شده در بک‌لاگ محصول گفتگو کنید. از جمله در موارد زیر:

  • چه مولفه‌هایی به بک‌لاگ افزوده شده‌اند؟
  • چه مولفه‌هایی حذف شده‌اند؟
  • چه مولفه‌هایی باز اولویت‌بندی شده‌اند؟
  • تیم به چه آموز‌ه‌هایی دست یافته است؟

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

هچمنین:

  • با هدف ارزیابی ریسک‌های احتمالی، مولفه‌های جدید را اندازه‌گیری کنید.
  • اسپایک‌هایی (Spikes) را برای اسپرینت (های) بعدی تعریف کنید تا علاوه بر افزایش یادگیری، ریسک‌ها تا حد امکان کاهش یابند.

بوم پالایش بک‌لاگ محصول

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

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

منبع: www.kaizenko.com

در صورت تمایل در شبکه‌های اجتماعی با من همراه باشید.

تلگرام

لینکدین

اینستاگرام