مولفه‌های بک‌لاگ محصول

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

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

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

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

در زمان تعریف و ایجاد هریک از PBIs، ممکن است مولفه‌ها بسیار کلی و در سطح بالا نوشته و ثبت شود، به‌گونه‌ای که تنها به عنوان یک یادآور (یا نگهدارنده جا – Placeholder) عمل کنند.

به مرور زمان و به موازات شفافیت بیشتر اطلاعات یا افزایش اولیت یک مولفه، آن PBI به مرور بهبود و تفضیل می‌یابد و در عین‌حال پالایش (Refined) خواهد شد. در نهایت نیز هر مولفه به سطحی از شفافیت و جزییات خواهد رسید که اطلاعات آن برای اقدام موثر توسعه توسعه‌دهندگان (Developers) کافی باشد.

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

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

• برآورد مطلق (Absolute): معمولاً مبتنی بر زمان است؛ برای مثال، «این مولفه به حدود ۹ ساعت کار نیاز دارد».
• برآورد نسبی (Relative): از مقایسه یا قیاس استفاده می‌شود که به توسعه‌دهندگان امکان می‌دهد اندازه هر مولفه را در مقایسه و نسبت به مولفه‌های دیگر تخمین بزنند؛ مانند «استوری پوینت – Story Points» یا «T-Shirt Sizing».
• معیارهای جریان کار (Flow Metrics): مبتنی بر داده‌های تاریخی تیم مانند توان عملیاتی (Throughput) را شامل می‌شود.
• اندازه مناسب (Right Sizing): در چارچوب آن مولفه‌هایی شناسایی می‌شوند، که به اندازه کافی کوچک هستند تا در یک اسپرینت کامل شوند (معمولا در قالب رویکردهای مبتنی بر جریان). برای مثال توسعه‌دهندگان در چارچوب گفتگوی تیمی PBIs را از منظر امکان تکمیل (انطباق با DOD یا Definition of Done یا تعریف انجام‌شده) در چارچوب یک اسپرینت بررسی می‌کنند و در صورتی که مولفه‌ای قابل تکمیل در یک اسپرینت نباشد، لازم است به مولفه‌های کوچک‌تر تجزیه شود.

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

توضیح تکمیلی: در چارچوب راهنمای اسکرام (Scrum Guide)، هر یک از سه مصنوع اصلی (Artifacts) دارای یک تعهد (Commitment) است و تعهد Product Backlog، هدف محصول است. هیچ قالب و چارچوب مشخصی برای تعریف و تنظیم هدف محصول وجود ندارد و هیچ الزامی نیز برای افق برنامه‌ریزی در هنگام تعیین هدف محصول تصریح نشده‌است. در چارچوب اسکرام تاکید شده‌است در هر مقطع زمانی لازم است تنها یک هدف محصول تعریف و بیان شده‌ باشد، این هدف باید یا محقق شود و یا پیش از تعریف هدفی جدید، کنار گذاشته شود.

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

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

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

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

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

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

از اقدام‌های بهبود مولفه‌های بک‌لاگ محصول که به آماده شدن آنها برای این‌که کار بر رویشان آغاز شود، تحت عنوان «پالایش – Refinement» یاد می‌شود.

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

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

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

با این‌حال و به‌منظور ایجاد شفافیت بیشتر و نیز دستیابی به درک و برداشت مشترک، رویه حرفه‌ای و توصیه شده آن است که مالک محصول، توسعه‌دهندگان و ذی‌نفعان مرتبط به طور مستمر و منظم در گفتگوهای متمرکز بر پالایش بک‌لاگ محصول مشارکت داشته باشند. در عین حال باید توجه داشت که تیم‌های «خود مدیریتی – Self-managing» (و خود سامانده) در مورد زمان انجام پالایش و نیز حاضران در هر جلسه یا گفتگو تصمیم‌گیری می‌کنند.

منبع:  www.scrum.org

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