دسته: مدیریت پروژه چابک
شش قدم تا مدیریت موفقتر انتشار نرمافزار با جیرا
یکی از سوالات مهمی که هر مهندس نرمافزاری لازم دارد تا به آن پاسخ دهد این است که «چه زمانی تغییرات جدید منتشر خواهند شد؟». البته دانستن پاسخ این سوال تنها با مسئول توسعهٔ نرمافزار (دولوپر) نیست. رهبر تیم لازم است که بداند چه زمانی آمادهٔ رفتن به مرحلهٔ بعدی هستند. مدیر پروژه نیز لازم است از این موضوع مطلع باشد تا بتواند برای اطلاعرسانی در خصوص ویژگیهای جدید برنامهریزی کند. جدای از این توسعهدهندهٔ نرمافزار برای دریافت بازخورد کارهای انجام شده لحظه شماری میکند. به طور کلی میتوان پاسخ این سوال را یک تلاش تیمی دانست. در دنیای دواپس (DevOps)، تغییرات جدید چند مرحله در روز با برنچ master ترکیب (Merge) میشوند، ولی دانستن این که تغییرات جدید چه زمانی آماده میشوند چندان آسان نیست. توسعهدهندگان کنترل کامل انتشار تغییراتشان برای کاربران نهایی را در دست دارند، همین امر نیز اهمیت قابلیت پیگیری تغییرات (Tracking) را دو چندان میکند. از این طریق است که تیمهای IT و عملیات (Operation) میتوانند در زمان رویدادهای غیرمنتظره دقیقا مشخص کنند که کدام تغییرات در به وجود آمدن مشکلات تأثیرگذار بودهاند. خبر خوب این است که بخش عمدهای از این روند میتواند توسط نرمافزارهای Jira و یا Jira Service Desk و به روش خودکار انجام شود. در ادامه ۶ قدم مفید برای بهره گیری از پلتفورم جیرا در جهت مدیریت بهتر انتشارهای نرمافزار را با هم مرور میکنیم. ۱) با استفاده از مسائل (Issues) جیرا، تغییرات را مشخص کنید تعریف یک تغییر چیست؟ آیا میتوان یک کامیت (Commit) را تغییر دانست؟ یا هر تغییر میتواند شامل چند کامیت مجزا باشد؟ عموما پیادهسازی یک تغییر قابل انتشار شامل چند کامیت مجزا میباشد. یکی از پر استفادهترین روشهای مدیریت تغییرات در نرمافزارهای مدیریت نسخه (Version Control) ساخت برنچ ویژگیهای جدید است. وقتی که کار بر روی آنها به اتمام رسید نیز مجموعهٔ تغییرات ثبت شده در برنچ با استفاده از یک درخواست بررسی (Pull Request) با برنچ Master ترکیب میشوند. یک درخواست بررسی تعریف دقیقتری از یک واحد از تغییرات ارائه میکند. با این حال معمولا تغییرات کوچک اما مهم دیگری نیز لازم است تا بعد از ثبت درخواست بررسی بر روی برنچ اعمال شوند. برای مثال، ممکن است رنگ یک جزء از رابط کاربری نیاز به تغییر داشته باشد و یا جملهبندی یک بخش از رابط بتواند با کمی تغییر بهتر شود. در چنین شرایطی ممکن است شما چند «درخواست بررسی» داشته باشید که نهایتا یک تغییر منطقی را شامل میشوند. به جای ترکیب تمام این درخواستها با یکدیگر، شاید بهتر باشد که تمامی آنها را به عنوان یک واحد از تغییرات و در کنار هم ثبت کنید. اینجاست که سیستم مسائل جیرا وارد میشود. جیرا نه تنها روند کارهای شما را تعقیب میکند، بلکه میتواند اشخاص مرتبط با موضوع را از ثبت تغییرات جدید مطلع سازد. هر شخصی در سازمان شما میتواند مسائل جیرا را زیر نظر (Watch) داشته باشد تا از ثبت دیدگاههای جدید و یا تغییر در روند انجام آنها بلافاصله مطلع گردد. ۲) روند کاری (Workflow) انتشار نرمافزارتان را در جیرا تعریف کنید به طور پیشفرض، روندهای کاری مرتبط با مدیریت انتشار نرمافزار در جیرا پیادهسازی نشدهاند. اما از آنجایی که پلتفورم جیرا قابلیت انعطافپذیری بالایی دارد، کاربران را قادر میسازد تا حالتهای (Status) بیشتری را برای پیگیری وضعیت انتشار نرمافزار تعریف کند. روند کاری پیشفرض جیرا به صورت زیر شامل سه وضعیت میباشد: حالا بیایید چند وضعیت جدید به این ترکیب اضافه کنیم. برای پوشش مسئلهٔ پیش روی ما، لازم است به جای انتقال بلافاصله از حالت «در حال انجام» (In Progress) به وضعیت «انجام شده» (Done) وضعیتهای زیر نیز تعریف شوند: در حال انتظار برای انتشار (Awaiting Release): به این معناست که کار مربوطه به صورت کامل انجام شده و حالا آمادهٔ انتشار است. منتشر شده برای تست (Released to Staging): مشخص میکند که روند انتشار برای محیط تست به صورت کامل انجام شده است. منتشر شده برای محیط اصلی (Release to Production): هورا! تغییرات جدید به دست کاربر نهایی رسیده است. در تصویر زیر نمایی از چگونگی افزودن این وضعیتها روی روندکاری پایهٔ جیرا را مشاهده میکنید. برای راهنمایی بیشتر در این خصوص میتوانید با تیم پشتیبانی پارسدانیسان تماس حاصل فرمایید: ۳) بردهای چابک (Agile) را تنظیم کنید وقتی که روندکاری جدیدتان را پیادهسازی کردید، به بخش تنظیمات پروژههای مورد نظرتان وارد شوید و روند کاری جدید را برای آنها فعال کنید. اگر توسعهدهندگانتان از بردها استفاده میکنند، وضعیتهای جدید را به بردهایشان اضافه کنید. یک راه آسان برای انجام این کار این است که به صفحهٔ تنظیمات برد وارد شده و روی بخش ستونها (Columns) کلیک کنید. در اینجا میتوانید وضعیتهای جدید را بکشید و در ستون Done رها کنید: حالا، هر زمانی که توسعهدهندهای بخواهد کارت مسئلهای را از برد «در حال انجام» به «انجام شده» منتقل کند، با پیغامی روبرو خواهند شد که از آنها میخواهد وضعیت درست را در این خصوص مشخص کند. اینجاست که میتوانند وضعیت انتشار یک ویژگی را مشخص کنند: ۴) مسائل جیرا را با انتشارها مرتبط کنید با فرض بر این که انتشارها از طریق یک مخزن گیت (Git Repository) انجام میگیرند، میتوانیم از تاریخچهٔ کامیتها به منظور اطمینان یافتن از انتشار تغییرات درست بهره بگیریم. برای این کار، لازم است که بتوانیم کامیتها را به مسئلهٔ مربوطه در جیرا متصل کنیم، تا بتوانیم بفهمیم که کدام تغییر با کدام مسئله در ارتباط است. یک راه برای دستیابی به این منظور، افزودن کلید مسئلهٔ جیرا (Issue Key) به اول پیغام ثبت شده به همراه کامیت است: git commit -am ‘PROJ-255: change publish button colour to blue’ ممکن است بگویید که این کار مقداری سربار اضافه به روند توسعه اعمال میکند، اما مرتبط کردن مسئله با هر کامیت یک Best Practice محسوب میشود، چرا که قابلیت ردگیری درست و آسان تغییرات را فراهم میکند. راه حل جایگزین دیگر این است که کلید مسئله را در نام برنچ شامل تغییرات وارد کنید که روند مرتبط سازی کلید و کامیت مربوطه را در آینده آسانتر میکند. نکته: اگر با استفاده از جیرا برنچ خود را ایجاد کنید، به صورت خودکار نام مسئله برای برنچ جدید انتخاب میشود. ۵) تمامی تغییرات مرتبط برای انتشار بعدی را پیدا کنید حالا به مهمترین مرحله از […]
معرفی ابزار جیرا از شرکت اطلسیان
معرفی ابزار جیرا (Jira) ارائه شده از طرف شرکتاطلسیان، یک ابزار مدیریت پروژه و بروسه با قابلیت پیگیری باگها (Bug Tracking) برای پروژههای نرمافزاری و پیگیری مشکلات (Issue Tracking) است. اطلسیان از سال ۲۰۰۲ به توسعهٔ این پروژه پرداخته و نام جیرا که مخفف لغت Gojira (در ژاپنی به معنای Godzilla) است، را با طعنه به رقیب اصلی و متنباز این ابزار یعنی Bugzilla برای آن برگزیده است. این ابزار در حالت معمول به منظور پیگیری باگها و مسائل مربوط به پروژههای نرمافزار و اپلیکیشنهای موبایل مورد استفاده قرار میگیرد و دلیل اصلی آن ویژگیهای کاملاً مناسب داشبورد این ابزار جهت مدیریت بهینهٔ این موارد است. همچنین در حالت پیشرفتهتر این ابزار قادر است نقش یک ابزار مدیریت پروژهٔ کامل و بی نقص را در تیمهای نرمافزاری بر عهده گیرد. علاوه بر این، با استفاده از مجموعهٔ وسیعی از افزونههای ارائهشده در مارکت اطلسیان و یا از طریق توسعهٔ افزونه به وسیلهٔ رابط ارائهشده، میتوان این ابزار را کاملاً بسته به نوع نیاز تیمهای هدف شخصیسازی نمود. بر اساس گزارش شرکت اطلسیان در ماه اوت ۲۰۱۷ بیش از ۸۹۰۰۰ شرکت از ۱۲۲ کشور جهان از این محصول بهره میگیرند. از جمله معروفترین این شرکتها میتوان به موارد زیر اشاره کرد: شرکت خودروسازی آئودی سازمان فضایی آمریکا ناسا شبکه اجتماعی توییتر وبسایت انتشار موسیقی اسپاتیفای و بسیاری مواردی دیگر در زمینههای مختلف و با تعداد کارمندان مختلف (از کمتر از ۵۰ نفر تا شرکتهایی با بیش از ۱۰۰۰ کارمند) که میتوانید برای مشاهدهٔ لیست و توضیحات مربوطهشان به این صفحه مراجعه کنید. ابزار جیرا با استفاده از زبان جاوا توسعه داده شده که امکان میزبانی سرور وب آن را بر روی تمامی سیستمعاملهای مرسوم فراهم میکند. علاوه بر این، با بهرهگیری از امکانات ارتباطی جیرا (نظیر REST, SOAP و XML-RPC) امکان اتصال این ابزار با دیگر ابزارهای مورد استفاده در سازمان نظیر نرمافزارهای گفتگو، مدیریت مخازن کد و غیره فراهم شده است. این ابزار در سه بستهٔ متفاوت زیر که کاربریهای مناسب خودشان را دارند عرضه میشود: Jira Core: این بستهٔ اصلی جیرا و بدون شخصیسازی پیشفرض میباشد که میتواند در هر نوع پروژهای مورد استفاده قرار گیرد. Jira Software: این بسته همراه با ویژگیهای مناسب تیمهای نرمافزاری ارائه میشود. Jira Service Desk: این بسته نیز مناسب تیمهای فناوری اطلاعات و پشتیبانی ارزه شده است. چرا جیرا؟ با توجه به نیاز روز افزون و ماهیت پویای پروژههای امروزی، ابزارهای مدیریت پروژهٔ متفاوتی به وجود آمدهاند که هر کدام نقاط قوت و ضعف مخصوص به خود را نیز دارا هستند. با این حال میتوان نکات زیر را از جمله برتریهای جیرا دانست که مورد استقبال کاربران آن قرار گرفته است: ساختار قوی نرمافزار در جهت مدیریت پروژه. سادگی در امکان افزودن وظایف (Tasks)، ویژگیهای جدید، باگها و اشکالات پروژه از نیازهای اصلی یک ابزار مدیریت پروژه است که جیرا با کیفیت بالایی از آن پشتیبانی میکند. انعطافپذیری بالای داشبورد جیرا این امکان را فراهم میکند که آن را کاملا متناسب با ساختار پروژهها و نیاز تیم شخصیسازی کنید و با اعضای تیم به اشتراک بگذارید. این ویژگی به افراد دخیل در پروژه کمک میکند که در هر لحظه بتوانند از وضعیت کلی پروژه، پیشرفتها و موانع مرتبط با هر موضوع مطلع شوند و در صورت نیاز به بررسی و رفع آن موارد بپردازند. مدیریت پروسههای مورد نیاز جهت انجام و تکمیل یک پروژه با استفاده از جیرا این امکان را فراهم میکند که چگونگی تعریف یک کار، پیشرفت آن، بررسی آن و نهایتا تکمیل نتیجه را در یک قالب مشخص برای پروژههایی با پیچیدگی بیشتر تعریف و کنترل کنید. در موارد مرتبط با پروژههای نرمافزاری، جیرا امکان استفاده از مدلهای توسعهٔ چابک (Agile)، Kanban (مدل توسعهٔ طراحی شده توسط تویوتا که معروفترین پیادهسازی فعلی آن مربوط به ابزار رایگان Trello است) و آبشاری (Waterfal) در مدیریت چرخهٔ عمر نرمافزار (SDLC) را فراهم میکند. مجموعهٔ وسیعی از افزونهها که میتواند نیازهای زیادی را برطرف سازد. به عنوان نمونه، یکی از معروفترین افزونهها Tempo نام دارد که میتواند به افراد تیم در تهیهٔ گزارش زمانی مربوط به هر بخش از پروژه کمک کند. علاوه بر این مدیران تیم (یا هر پروژه) میتوانند با استفاده از همین افزونه و گزارشهای تهیه شده توسط افراد تیم، به برآورد هزینهها و زمان صرف شده نیز بپردازند. امکان مدیریت دسترسی تمامی بخشهای جیرا نیز این ویژگی را حتی تا کوچکترین اجزای ارئه شده توسط این ابزار (فیلدها) فراهم میکند. با استفاده از این امکان مدیران تیم یا پروژه میتوانند امکان دسترسی اعضای تیم به تکتک قسمتهای ابزار را به دقت و متناسب با نیاز خود ویرایش و مدیریت کنند. امکان ویرایش روندهای کاری (Workflows) نیز به کاربران اجازه میدهد تا کلیهٔ ساختارهای تعریف شده را بسته به نیاز پروژه ویرایش کنند. به عنوان مثال میتوان یک تجربهٔ کاربری (User Story) مشخصی را تعریف نمود و آن را در دو گروه وظیفهٔ اصلی و وظایف جزئی تقسیم کرد تا تمامی مراحل انجام مربوط به یک مسئله زیر یک ساختار کلی تعریف شوند و قابل پیگیری باشند. ویکی جیرا نیز امکان اشتراک مدیریت شدهٔ اطلاعات مربوط به هر پروژه را بین کاربران فراهم میکند. علاوه بر این افراد تیمها میتوانند اطلاعات را با اعضای دیگر پروژهها نیز به اشتراک گذاشته و به کسب دیدگاههای دیگر تیمها در خصوص اطلاعات ارائه شده بپردازند. امکان همگام سازی جیرا با دیگر ابزارها و خصوصا امکان خودکار سازی فرآیندهای تکراری اما حیاتی پروژه نیز به بازدهی تیمها کمک شایانی میکند. به عنوان مثال میتوانید فرآیند تعریف یک باگ جدید پس از شکست (Fail) یک تست نرمافزاری (Unit test) را خودکار سازی نموده و از آن بهره بگیرید. قابلیت آسان گسترش استفادهٔ جیرا در تعداد پروژههای زیاد بدون داشتن نگرانی در خصوص کاهش کارایی (Performance) ابزار. علاوه بر موارد ذکر شده، جیرا در مقایسه با دیگر رقبای خود نیز در جایگاه بالایی قرار میگیرد. به عنوان نمونه، جدول زیر این ابزار را با Bugzilla، دیگر ابزار معروف مدیریت پروژه که به صورت متنباز (و رایگان) ارائه میشود مقایسه میکند: ویژگی باگزیلا جیرا لایسنس رایگان پولی رتبهبندی مسائل با استفاده از کشیدن و رها کردن ندارد دارد استفاده از ابزارکهای شخصیسازی شده در داشبورد ندارد دارد پیگیری بلادرنگ انتشارهای جدید ندارد دارد مصرف منابع سرور کم قابل […]
روش NPS در اولویت بندی بکلاگ محصول
یکی از روشهای اندازهگیری رضایت مشتریان شاخص Net Promoter Score هست که میزان وفاداری یک مشتری را به محصولات شرکت اندازهگیری می کند. این شاخص درک و احساس مشتریان را در مورد محصول کمی سازی کرده و به مدیر محصول کمک میکند در مورد برنامه آینده توسعه تصمیمگیری کند. در ادامه با این تکنیک برای نحوه اندازهگیری رضایت مشتریان و همچنین برنامه آتی توسعه محصول نرمافزاری آشنا میشویم: در این روش ابتدا در یک فرم نظرخواهی NPS یک سوال در مورد محصول پرسیده میشود، برای مثال در اینجا سوال شده است که “چقدر مایل هستید که محصول Confluence را به دوستان و همکاران خود پیشنهاد دهید”؟ پاسخی که کاربر فراهم خواهد کرد در سه گروه Passives، Promoters و Detractors دستهبندی خواهد شد. گروه اول کسانی هستند که امتیاز ۹ و ۱۰ را انتخاب میکنند و جزو مروّجین محصول هستند، گروه دوم امتیاز ۷ و ۸ را انتخاب کرده و بهعنوان کاربر منفعل در نظر گرفته میشوند و گروه آخر گروهی هست که امتیاز ۰ تا ۶ را انتخاب خواهد کرد و مشتری ناراضی محصوب میشود. شاخص NPS با کم کردن درصد کاربران Detractors از کاربران Promoters محاسبه خواهد شد. برای مثال در حالتی که از ۱۰۰ فیدبک دریافت شده ۴۰ نفر Promoter؛ ۲۵ نفر Passive و ۳۵ نفر Detractors داشته باشیم، شاخص NPS برای آن برابر ۵% خواهد بود. این شاخص می تواند از ۱۰۰%- تا ۱۰۰%+ درصد متغیر باشد. بعد از انتخاب امتیاز توسط کاربر از وی خواسته میشود، نظر خود را در ارتباط با امتیاز داده شده لحاظ کند: مرحله ۱: دسته بندی صدای مشتری مدیر محصول میتواند تمامی این فیدبکها را مشاهده کرده و آنها را به صورت دستی آنالیز و دستهبندی کند، حالت دیگر با استفاده از ابزارهای آنالیز متن جهت دستهبندی این درخواست ها اقدام میشود. در این تصویر دو فیدبک مختلف از مشتری برای Confluence دریافت شده است. مورد اول در گروه Promoters ها قرار دارد و اگرچه ما از دیدن آن خوشحال خواهیمشد، اما هیچ اطلاعاتی در مورد اقدامات آتی برای ما فراهم نخواهد کرد. اما مورد دوم، به صورت خاص حاوی اطلاعاتی است که مشتری بابت آنها از محصول ناراضی بوده است. نارضایتی مشتری در این درخواست در یک پایگاه داده به صورت زیر با دو لیبل Usability و Formatting وارد میشود. حال فرض کنید درخواست زیر را نیز دریافت کردهایم: این درخواست ۲ لیبل جدید به جدول قبل اضافه خواهد کرد: با دریافت فیدبکهای جدید این جدول به مرور کامل تر خواهد شد. لازم به یادآوری است که در اینجا برای فیدبکهای مثبت لیبلی به جدول اضافه نخواهد شد. به طور مثال چنانچه فیدبک زیر را دریافت کنیم لازم است که لیبل مربوطه را برای Performance محسوب کنیم و ارتباطی با لیبل Table ندارد. Table features are great! But I wish Confluence was faster. مرحله ۲: تجزیه و تحلیل نتایج برای تجزیهوتحلیل اطلاعات حاصله در این مرحله لازم است ابتدا تعداد کل آیتمهای هر لیبل رو بشماریم: سپس زیرمجموعهها را پاک کرده و جدول را اولویت بندی کنیم: چنانچه اطلاعات دیگری در اختیار نداشته باشیم، براساس این جدول سراغ Performance که آیتم دارای بالاترین اولویت هست، خواهیم رفت. اما لزوما قرار نیست این آیتم بیشترین رضایت و خوشحالی را برای مشتریان فراهم سازد. برای حل این مشکل شاخص NPS مجددا برای هر حوزه محاسبه شده و در ستونی دیگر مطابق زیر آورده می شود: با لحاظ کردن این شاخص مشاهده می کنیم اگر چه شاخص Performance تعداد دفعات بیشتری در فیدبک کاربران ذکر شده است، اما امتیاز رضایت بالاتری در مقایسه با گزینه Tables دارد و اگر هدف ما خوشحال سازی و افزایش رضایت مشتریان هست، بهتر است سراغ موارد مربوط به Tables برویم. شما از چه روشی برای پروژه های خود استفاده می کنید؟ برای تهیه این نوشه از منابع زیر استفاده شده است: http://blogs.atlassian.com/2015/11/prioritize-features-using-nps/
استفاده از نظرات کاربران در توسعه نرم افزار چابک
در این نوشته راهحل شرکت اطلسیان برای جمع اوری نظرات کاربران بررسی شده است. مرحله اول: جمع آوری نظرات کاربران در توسعه نرمافزار چابک،فرایند دریافت بازخورهای مشتریان همزمان با ارائه ویژگیهای جدید محصول آغاز خواهد شد. برای جمعآوری فیدبکهای مشتریان ممکن است از کانالهای زیر استفاده میشود: اطلاعات دریافتی از این کانالها به UserStory تبدیل خواهند شد. چنانچه برای شما امکانپذیر باشد، شاید بهتر باشد که ارتباط حضوری با مشتری برقرار کرده و از نزدیک با وی صحبت کنید. با این کار هم درک بهتری از نیاز مشتری خواهید داشت و هم متوجه خواهید شد که اکنون چه مشکلاتی با محصول دارد و در صورت رفع آن مشکل به چه چیزی دست خواهد یافت. در شرکت اطلسیان یکی از کانالهای ورودی درخواست های مشتریان، پرتال jira.atlassian.com است که کاربران جیرا می توانند درخواستهای رفع باگ، توسعه و ویژگی جدید خود را مطرح کنند و یکی از امکانات آن این است که باقی کاربران با مشاهده آن میتوانند موافقت خود برای پیاده سازی آن را توسط Vote دادن به issue اعلام کنند. مرحله دوم: مستند سازی نظرات کاربران در ادامه تمامی فیدبکهای دریافت شده از کاربر در داخل Confluence در تمپلیت Product Requirement به ازای هر ایشو ایجاد خواهد شد. در این صفحه لینک تمامی منابع و کانالهایی که یک Story خاص از آن اقتباس شده است، مشخص خواهد شد تا تمامی ذینفعان پروژه در هر زمان که نیاز داشته باشند به آن دسترسی داشته باشند. مرحله سوم: انتقال نظرات به بکلاگ محصول هر ویژگی که قرار است در محصول/پروژه در آینده انجام شود باید در بکلاگ مربوطه لیست شود. Storyهایی که داخل بکلاگ قرار میگیرند، به روشهای مختلف اولویتبندی شده و تیم توسعه براساس این اولویتها برنامه اسپرینتهای اتی خود را مشخص خواهد کرد. یکی از تکنیکهای معمول برای اولویت بندی ایشوها تکنیک MoSCoW است. این تکنیک خلاصه شده چهار عبارت زیر است: – Must Have: موارد لازم و ضروری که در برنامهریزی فعلی باید به آن پرداخته شود. مفهموم Failure یک اسپرینت در این موارد وجود دارد و چنانچه آیتمی در این گروه در انتهای اسپرینت به اتمام نرسد، پروژه در آن بازه ناموفق بوده است. – Should Have: موارد مهم و غیر ضروری که چنانچه در برنامه زمانی فعلی به آن برسیم خوب است، اما لزومی نیست. این موارد در اسپرینت های اینده به Must Have تبدیل میشوند. – Could Have: این موارد در راستای بهبود تجربه کاربر و رضایت مشتریان است، این موارد مطلوب هستند و غیر ضروری. – Won’t Have: این موارد دارای کمترین اهمیت انجام هستند و می توانند هرگز انجام نشوند. در توسعه محصولات نرم افزاری (محصول به این مفهوم که سفارش مشتری نبوده است.) تمرکز بر ارائه خواسته های مشتری، کلید موفقیت سازمان و رضایت بیش از پیش مشتریان است. اما لزوما آیتمهای بکلاگ براساس درخواستهای مشتریان اولویتبندی نخواهند شد. به طور مثال ممکن است برای پیادهسازی یکی از خواستههای مشتری نیاز باشد که تغییرات بنیادینی در نرمافزار پیاده شود، مثلا برای بهبود تجربهکاربری ممکن است نیاز به طراحی یک API داشته باشیم که طبیعتا طراحی API مورد نظر از اولویت بالاتری برخوردار خواهد بود. مورد دیگر حائز اهمیت این مورد است که لزوما آیتمهای با اولویت بالا وارد برنامهریزی اسپرینت جدید نخواهند شد؛ بلکه همگام بودن این موارد نیز مهم است، به عبارت دیگر برای هر اسپرینت یک هدف مشخص تعریف شده و آیتم هایی که مرتبط با آن هدف باشند، برای اسپرینت مورد نظر انتخاب خواهند شد. اولویت بندی بکلاگ محصول هم می تواند متکی بر art و تجربه مدیر پروژه/محصول و اعضای تیم توسعه باشد و هم میتواند بر اساس Science و روشهای علمی انجام پذیرد و انتخاب یکی از این دو حالت یا حالت بینابین بستگی به مدیر محصول و تیم مربوطه دارد. در این نوشته روش Net Promoter Score با به اختصار NPS معرفی شده است. براساس نظر مدیر محصول Confluence آیتم های بکلاگ محصول در یکی از ۳ دسته زیر قرار خواهند گرفت: – Now (اسپرینت جاری) – Next ( اسپرینت های آتی) – Some Day – آیتم های Some Day نیازی به صرف وقت ندارد، منتهی چند وقت یکبار اولویت بندی خواهند شد. – برای موارد Next و Now باید به اندازه کافی وقت بگزاریم. – در اولویت بندی آیتم های Some Day برخلاف آیتم های Next و Now به صورت Time-box عمل می کنیم و در پایان ۲ یا ۳ بار اولویت بندی این آیتمها، آیتمهائی که هرگز اولویتشان جابهجا نشده باشد، برای همیشه بسته خواهند شد. شما آیتمهای بکلاگ خود را با چه روشی اولویتبندی می کنید؟ برای تهیه این نوشه از منابع زیر استفاده شده است: http://blogs.atlassian.com/2015/12/how-to-capture-and-prioritize-customer-feedback-in-agile-development/ http://blogs.atlassian.com/2015/12/inside-atlassian-prioritizing-customer-feedback-backlog-grooming/