اگر با اسکرام کار کرده‌اید، حتما تجربه کردید که اکثر تیم‌ها با Backlog refinement یا جلسه تعریف بک‌لاگ مشکل دارند. بیایید علت این موضوع را بررسی کنیم. Backlog refinement یا پالایش و تعریف بک‌لاگ محصول یکی از فعالیت‌های مهم اسکرام است. یک فرایند جادویی که یک آرزو و رویا را توسط تیم توسعه به محصولی کاربردی، تبدیل می‌کند. در راهنمای رسمی‌اسکرام تنها پاراگراف زیر درباره این فرایند آورده شده است:
پالایش و تعریف بک‌لاگ محصول شامل اضافه کردن جزئیات، تخمین زمانی و رتبه بندی آیتم بک‌لاگ محصول می‌باشد. پالایش بک‌لاگ یک فرایند مداوم جهت بدست آوردن جزئیات آیتم‌های بک‌لاگ محصول در همکاری و تعامل بین تیم توسعه و مالک محصول می‌باشد. در طی تعریف بک‌لاگ محصول، آیتم‌ها مرور و مورد بازنگری قرار می‌گیرند. تیم اسکرام بر روی چگونگی و زمان انجام این فرایند تصمیم می‌گرند. این کار معمولا بیشتر از ۱۰% زمان تیم را نمی‌گیرد. هر چند که آنها هر زمانی توسط مالک محصول و یا در جهت نیل به اهداف مالک محصول می‌توانند به روز رسانی شوند.
به طور خلاصه بگویم: تا زمانی که این کار بیشتر از ۱۰% زمان شما را نگیرد، شما می‌توانید این فرایند تعریف بک‌لاگ را هر طور که دوست دارید انجام دهید. البته اگر هم زمان بیشتری برد در بعضی شرایط مشکلی وجود ندارد. با تنها همین پاراگراف خلاصه در راهنمای اسکرام، جای تعجبی نیست که خیلی از تیم‌ها در پالایش و تعریف بک‌لاگ محصول با مشکل مواجه می‌شوند.
یک backlog refinement موثر برای موفقیت اسکرام ضروری است.
بدون یک تعریف درست از بک‌لاگ‌ها، تخمین‌ها درست نیست و تیم فنی معماری نرم افزار را براساس فرضیات اشتباه طراحی خواهند کرد. قعالیت تیم، ارزش و خروجی کمتری خواهد داشت چون درک درستی از کاری که باید انجام دهند را ندارند و در نهایت ظرفیت تیم به سطح پایدار و قابل پیش بینی نخواهد رسید.
بک‌لاگ و اجتناب از سه نوع عدم قطعیت
کل فرایند Refinement مدیریت عدم قطعیت و ایجاد درک مشترک بین تیم است. با انجام درست این فرایند، تیم می‌تواند با اعتماد به نفس تخمین‌ها را انجام دهد و ارزش کسب و کاری مورد نظر را تحویل دهد.
هنگام انجام تعریف بک‌لاگ و پالایش و آنها سه موضوع مهم است که باید پوشش داده شود. این موضوع به شما کمک می‌کند تا اساس ساخت یک محصول درست ریخته و به درستی ریخته و ساخته شود.
- عدم قطعیت هدف: چرا ما می‌خواهیم این محصول را بسازیم؟
- عدم قطعیت نهایی: برای ساختن چه چیزی لازم داریم؟
- عدم قطعیت مفهومی: چگونه می‌توانیم آن را بسازیم؟
عدم قطعیت هدف: چرا ما می‌خواهیم این محصول را بسازیم؟
اولین موردی که هر مالک محصول باید در این جلسه مطرح کند، چرایی ویژگی‌هایی است که قرار است در محصول ساخته شود. ارزشی که از ساخت این ویژگی انتظار داریم، چیست؟ دنبال رسیدن به چیزی هستیم؟
ایجاد شفافیت در هدف تولید محصول، به تیم برای دادن بازخوردهای مناسب کمک می‌کند. شاید راه‌های دیگری نیز برای رسیدن به این هدف وجود داشته باشد. شاید تیم به شما بگوید اصلا نباید همچین ویژگی را در محصول ایجاد کنید چون ارزش مورد نظر را به وجود نخواهد آورد.
تعریف یک چرایی واضح، هنگام کد زدن به تیم آزادی در تصمیم گیری می‌دهد. همچنین تیم می‌تواند از هر راهکاری که برای پیاده سازی انتخاب می‌کند دفاع کند و برای آن منطق لازم را داشته باشد.
“ ممکن است محصول را درست بسازید، اما فراموش کردن ساخت محصول درست یک گناه مرگ آور است.”
شکست در تعریف شفاف هدف به این معناست که تیم شما نمی‌تواند در گرفتن تصمیمات درست کسب و کار، به شما کمکی کند. ممکن است محصول را درست بسازید، اما فراموش کردن ساخت محصول درست یک گناه مرگ آور است. شما مقدار زیادی تلاش برای ساخت محصول خواهید کرد اما خروجی هیچ ارزشی نخواهد داشت. آگاهی دادن به تیم در مورد چرایی و هدف و اهمیت انجام هر فعالیت بسیار مهم است. به این شکل تیم همیشه می‌تواند این هدف را در ذهنش نگه دارد.
بک‌لاگ و عدم قطعیت نهایی: برای ساختن چه چیزی لازم داریم؟
تیم توسعه محصول باید درک درست و شفافی از چیزی که باید بسازد، داشته باشد. در طول جلسه تعریف بک‌لاگ، مالک محصول شروع به توضیح ویژگی‌های مورد نیاز برای تیم می‌کند. تیم و مالک محصول همزمان بر روی چیزی که باید ساخته شود توافق می‌کنند و در مورد امکان پذیری فنی ساخت این محصول صحبت می‌کنند.
“مالک محصول تلاش می‌کند تا به بهترین و کامل ترین حالت توضیح نیازمندی‌های محصول دست پیدا کند و این توضیحات آنقدر شفاف باشد تا از بروز سوال‌های عجیب جلوگیری کند.”
زمانی که برای اولین بار درباره نیازمندی‌های یک ویژگی بحث می‌کنید، این تعاریف باید واضح باشند تا قابل بحث کردن باشند. همچنین این نیازمندی‌ها نباید با جزئیات بیش از حد بیان شوند زیرا باعث می‌شوند تا دامنه بحث‌ها از کنترل خارج شوند و باعث می‌شود تا از موضوع بحث جلسه دور شوید.
مالک محصول تلاش می‌کند تا به بهترین و کامل ترین حالت توضیح نیازمندی‌های محصول دست پیدا کند و این توضیحات آنقدر شفاف باشد تا از بروز سوال‌های عجیب جلوگیری کند. تعریف مشکلات توسط تیم باعث ایجاد یک درک مشترک می‌شود و تمام اعضای تیم متوجه می‌شوند که بر روی چه موضوعی کار می‌کنند.
اگر در طول جلسه، تیم شروع به پرسیدن سوال‌های زیاد کرد، این موضوع نشانه این است که مشکلات کامل تعریف نشده اند. بهترین کار لیست کردن تمام سوالات و تطبیق توضیحات به طوری است که جواب این سوالات در آنها باشند. تیم اسکرام در جلسه آینده این ویژگی‌ها را با هم بحث خواهند کرد.
اگر سوالی پرسیده نشود همزمان می‌تواند نشانه خوب و بدی باشد. اگر ویژگی دارای پیچیدگی باشد، باید با همه افراد صحبت کنید و مطمئن شوید تا همه نیازمندی‌ها را به درستی متوجه شده اند. بعضی مواقع تیم به دلیل وجود نیازمندی‌های زیاد خسته می‌شوند، و اعلام می‌کنند که تمام نیازمندی‌ها را متوجه شده اند.
عدم قطعیت مفهومی: چگونه می‌توانیم آن را بسازیم؟
وقتی که همه تیم به درک مشترکی از هدف و چیزی که باید ساخته شوند برسند، حالا نوبت آن است که درباره چگونگی ساخت آن صحبت کنند. اگر تیم ایده ای درباره نحوه ساختن محصول نداشته باشد، نمی‌تواند تخمینی درباره زمان اجرای ان ارائه کند. همچنین ریسک ساخت یک راهکار غیر قابل اعتماد از لحاظ فنی نیز افزایش پیدا می‌کند. این مساله خیلی مهم است که تیم اعتماد به نفس کافی برای ساخت محصول به صورت کامل را داشته باشد.
اگر تیم هیچ ایده ای درباره چگونگی ساختن محصول نداشته باشد، نوع برنامه ریزی متفاوت خواهد شد. در این حالت یک بازه زمانی مشخص می‌شود که در این زمان تیم باید درباره چگونگی ساختن محصول و ویژگی مطرح شده تحقیق کند. یکی از اعضای تیم مقدار ساعت مشخصی را برای یافتن این چگونگی درخواست می‌کند. در جلسه آینده، اعضای تیم درباره راه کار به دست آمده توضیح خواهند داد. حالا تیم به خوبی از آنچه که باید ساخته شود، چرایی آن و نحوه ساختن آن آگاه خواهد بود و می‌توانند برای برنامه ریزی تخمین زمانی مناسب ارائه دهند.
“عدم اطمینان نهایی باید به اندازه ای کم باشد که تیم بتواند با دقت کافی تخمین بزند و سرعت و ظرفیت پایدار را بدست آورد.“
هنگامی‌که تیم‌ها شروع به استفاده از اسکرام می‌کنند تمام سعی خودشان را می‌کنند تا تمام جزئیات را مشخص کنند و عدم قطعیت‌ها را تا جای ممکن کاهش دهند. به یاد داشته باشید لازم نیست تمام عدم قطعیت‌ها از بین برود فقط کافی است شما در محدوده امنی قرار بگیرید که در آن افراد به درک مشترک رسیده اند. عدم اطمینان نهایی باید به اندازه ای کم باشد که تیم بتواند با دقت کافی تخمین بزند و سرعت و ظرفیت پایدار را بدست آورد. همچنین در جلسه برنامه ریزی اسپرینت لازم نیست که با تمام جزئیات برنامه ریزی شود موضوعات غیرضروری مطرح شود.
درباره Epics
همانطور که متوجه شدید در این متن به صورت اگاهانه درباره نحوه برخورد با Epics در طول جلسه صحبت نشده است. Epics مسائلی هستند که آنقدر بزرگ و کلی اند که تیم برای کار کردن بر روی آنها باید آنها را خرد کند و به قسمت‌های کوچک تری تبدیل کند. شما می‌توانید تمام گام‌های مطرح شده در مقاله را درباره Epics نیز انجام دهید. گام آخر علاوه بر سه گام بالا، چگونگی خرد کردن Epics برای تیم توسعه محصول است. که اگر بلاگ تیم کمپ را دنبال کنید، به زودی مطلبی درباره آن آورده خواهد شد.
پذیرفتن عدم اطمینان و ایجاد درک مشترک
تمرکز تعریف بک‌لاگ محصول، بر روی مدیریت عدم اطمینان و ایجاد درک مشترک است. نگاه کردن به این فرایند از لنز سه عدم قطعیت مطرح شده، کمک می‌کند تا تمام این مسائل پوشش داده شود. شما با کاهش عدم قطعیت و روشن کردن کارها و ایجاد تعادل در آن، می‌تواند از صرف زمان‌های طولانی در جلسات برنامه ریزی جلوگیری کنید. و زمان تیم را به صورت بهینه مورد استفاده قرار دهید.
همه ما می‌خواهیم کاری کنیم که توانمندتر باشیم و محصولی با ارزش بیشتر را تحویل مشتری دهیم. اهدافتان را با تیمتان به اشتراک بگذارید آنها تنها افرادی هستند که در مسیر رسیدن به این اهداف طوری که انتظار آن را ندارید، شما را همراهی خواهند کرد.
