مدیریت Backlog در توسعه نرم‌افزار

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

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

در نگاه اول، همه چیز کاملا روشن است، یک لیست از کارها داریم که فردی مسئول توزیع کارهای این لیست است اما با این وجود مدیریت Backlog پیچیده‌تر از آن است که به‌نظر می‌رسد.

Backlog محصول

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

ویژگی‌های یک Backlog خوب محصول

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

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

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

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

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

نکات

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

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

کارهایی که باید بلافاصله انجام شوند (Definition of Ready) را در بالای لیست قرار دهید، این توافق نامه‌ای میان صاحب محصول و تیم توسعه در مواردی است که باید قبل از رفتن به مرحله توسعه، کارهایی انجام شده باشد.

مواردی که باید به آن‌ها توجه داشته باشید:

• توضیح‌ها: به لطف این مورد می‌توانید ارزش هر کار را تشخیص دهید.
• معیارهای پذیرش: به کمک این مورد می‌توانید از انتظارهای مشتری مطلع باشید و این امکان را به‌وجود می‌آورد تا تست‌های مناسبی بر روی محصول انجام دهید.
• طرح‌ها: اگر یک کار جدید گرافیکی باشد ارزش آن را دارد که به یک وظیفه در Backlog تبدیل شود.
• مسیر کاربر: اغلب در استفاده از زبان Gherkin می‌توانیم قدم‌های بعدی کاربر را تشخیص دهیم.

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

Sprint Backlog

حال اگر Backlog محصول خود را براساس موارد قبل تنظیم کرده‌اید می‌توانیم به سراغ Sprint Backlog برویم. در راهنمای اسکرام (Scrum) این مورد به صورت زیر توضیح داده شده است:

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

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

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

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

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

سوال اصلی در طول برنامه‌ریزی Sprint آن است که هدف Sprint بعدی چیست؟ بر این اساس، می‌توانیم برای رسیدن به هدف بعدی، وظایف مناسب را انتخاب کنیم و براساس اهمیت، هرکدام از کارها را در Sprint Backlog اولویت‌بندی کنیم.

مدیریت Backlog

اکنون به سخت‌ترین بخش یعنی مدیریت لیست کارها رسیده‌ایم، صرفا نوشتن وظایف، سازماندهی و برآورد آن‌ها در صورت به‌روزرسانی نکردن لیست‌هایمان، کار خاصی نخواهد بود. برای آسان‌سازی این فرایند می‌بایست همه به لیست‌ها دسترسی داشته باشند. بدین منظور از Scrum Board یا plain board که در دسترس عموم است، استفاده می‌کنیم. همان‌طور که قبلا اشاره کردیم، افراد دیگری وظیفه منظم نگه‌داشتن لیست‌ها را به عهده دارند. مثلا مسئولیت Sprint Backlog به عهده تیم توسعه است. اغلب اوقات لیست کارها در جلسه‌های روزانه به‌روز می‌شوند. این کار شامل قرار دادن کار در ستون و افزودن توضیح‌های مناسب به آن است. همه این‌ها به توافق تیم و نحوه تنظیم کارها توسط هیئت مدیره بستگی دارد.

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

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

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

جمع‌بندی

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

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

منبع: https://tsh.io/blog/backlog-management-in-software-development