backlog - بک‌لاگ

بک‌لاگ: تسلط بر تعریف و پالایش بک‌لاگ محصول

اگر با اسکرام کار کردهاید، حتما تجربه کردید که اکثر تیمها با Backlog refinement یا جلسه تعریف بک‌لاگ مشکل دارندبیایید علت این موضوع را بررسی کنیمBacklog refinement یا پالایش و تعریف بک‌لاگ محصول یکی از فعالیتهای مهم اسکرام استیک ‌فرایند جادویی که یک آرزو و رویا را توسط تیم توسعه به محصولی کاربردی، تبدیل میکنددر راهنمای رسمیاسکرام تنها پاراگراف زیر درباره این ‌فرایند آورده شده است:

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

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

[inlinetweet prefix=”” tweeter=”” suffix=””]یک backlog refinement موثر برای موفقیت اسکرام ضروری است.[/inlinetweet]

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

بک‌لاگ و اجتناب از سه نوع عدم قطعیت

کل ‌فرایند Refinement مدیریت عدم قطعیت و ایجاد درک مشترک بین تیم استبا انجام درست این ‌فرایند، تیم میتواند با اعتماد به نفس تخمینها را انجام دهد  و ارزش کسب و کاری مورد نظر را تحویل دهد.

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

  • عدم قطعیت هدفچرا ما میخواهیم این محصول را بسازیم؟
  • عدم قطعیت نهاییبرای ساختن چه چیزی لازم داریم؟
  • عدم قطعیت مفهومیچگونه میتوانیم آن را بسازیم؟

عدم قطعیت هدفچرا ما میخواهیم این محصول را بسازیم؟

اولین موردی که هر مالک محصول باید در این جلسه مطرح کند، چرایی ویژگیهایی است که قرار است در محصول ساخته شودارزشی که از ساخت این ویژگی انتظار داریم، چیست؟ دنبال رسیدن به چیزی هستیم؟

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

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

[inlinetweet prefix=”” tweeter=”” suffix=””]“ ممکن است محصول را درست بسازید، اما فراموش کردن ساخت محصول درست یک گناه مرگ آور است.”[/inlinetweet]

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

بک‌لاگ و عدم قطعیت نهاییبرای ساختن چه چیزی لازم داریم؟

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

[inlinetweet prefix=”” tweeter=”” suffix=””]“مالک محصول تلاش می‌کند تا به بهترین و کامل ترین حالت توضیح نیازمندی‌های محصول دست پیدا کند و این توضیحات آنقدر شفاف باشد تا از بروز سوال‌های عجیب جلوگیری کند.”[/inlinetweet]

زمانی که برای اولین بار درباره نیازمندیهای یک ویژگی بحث میکنید، این تعاریف باید واضح باشند تا قابل بحث کردن باشندهمچنین این نیازمندیها نباید با جزئیات بیش از حد بیان شوند زیرا باعث میشوند تا دامنه بحثها از کنترل خارج شوند و باعث میشود تا از موضوع بحث جلسه دور شوید.

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

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

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

عدم قطعیت مفهومیچگونه میتوانیم آن را بسازیم؟

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

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

[inlinetweet prefix=”” tweeter=”” suffix=””]“عدم اطمینان نهایی باید به اندازه ای کم باشد که تیم بتواند با دقت کافی تخمین بزند و سرعت و ظرفیت پایدار را بدست آورد.“[/inlinetweet]

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

درباره Epics

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

پذیرفتن عدم اطمینان و ایجاد درک مشترک

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

همه ما میخواهیم کاری کنیم که توانمندتر باشیم و محصولی با ارزش بیشتر را تحویل مشتری دهیماهدافتان را با تیمتان به اشتراک بگذارید آنها تنها افرادی هستند که در مسیر رسیدن به این اهداف طوری که انتظار آن را ندارید، شما را همراهی خواهند کرد.



تیم کمپ سیستم آنلاین مدیریت پروژه و مدیریت تیم است. ما به تیم ها کمک می کنیم تا با سرعت و به سادگی وظایف، گفتگوها، فایل ها و فعالیت های تیمی و کسب و کار خود را به صورت آنلاین مدیریت کنند و ریسک های پروژه و کار تیمی خود را کاهش دهند.

شاید علاقه مند باشید  بستن پروژه: چطور یک پروژه موفق را به طور کامل ببندید
اشتراک‌گذاری

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *