https://virgool.io/feed/@m_274381 fa 2026-04-15 06:30:42 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_274381 https://virgool.io/@m_274381/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DB%8C-%D9%85%D8%A7-%D8%AF%D8%B1-%D8%B3%D8%A7%D8%AE%D8%AA-%D9%85%D8%AA%D8%B1%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%D8%A7%D8%AC%D8%A7%DB%8C%D9%84-%D9%88-roadmap-%D8%AF%D8%B1-jira-tfe3xuim29xs من خیلی جا ها که برای پیاده سازی کانسپت اجایل و چارچوب هایی مثل اسکرام و کانبان با یه صورات کلی فرایند های اجایل حضور داشتم همیشه بحث استیمیت و لاگ تایم زدن و بحث های همیشگی نحوه تخمین دادن و تکنیک هاش بوده و الان هم توی کامینیتی های اجایل همیشه این بحثه باز هست و داغ. اما اگه سوال واقعی تر توی سازمان یا اون تیم این بوده که چقدر به گرفتن دیتا از توسعه دهنده ها و تیم لید هاشون متعهدیم یا بهتر بگم چقدر میشه انتظار داشت که افراد تیم دیتا های آپدیت شده مثل لاگ تایم ، میزان پیشرفت کار ها و ایستیمیشن ها رو وارد کنن تا واقعا به سمت Evidence Based تحلیل اسکوپ کاری بریم چی؟و از مسائل قبلی عبور کرده باشیم چی؟. من بعد از مدت ها با تیمی در زمینه اجایل و پیاده سازی جیرا همکاری کردم که این موضوع خیلی جدی توش دنبال میشد و تمامی پرفورمنس تیم بر اساس دیتای وارد شده در ابزار سنجیده میشد و بعد از حدود 6 ماه به صورت یک کالچر غالب دراومده بود و تمامی اون صحبت هایی که توی خیلی از تیم ها میشنیدم که چقدر وقت مارو میگیرن با دیتا وارد کردن از بین رفته بود. من نشانه هایی از قهری بودن دیتا اینتری نمیدیدم و همگی به درک درستی از Visual بودن دیتا رسیده بودن.اما مشکل وقتی جدی میشه که می‌خوای از این داده‌ها برای مدیریت مبتنی بر شواهد (Evidence-Based Management) استفاده کنی.من توی یک پروژه واقعی با چند محصول و چند تیم فنی این موضوع رو جدی دنبال کردم. بعد از حدود ۶ ماه، چیزی که اول به نظر می‌رسید «بار اضافی» باشه، تبدیل شد به یک فرهنگ غالب تیمی. هیچ‌کس حس نمی‌کرد دیتا اینتری اجبار یا قهره، بلکه همه فهمیده بودن که ویژوال بودن دیتا = شفافیت و تصمیم‌گیری بهتر.۳ چالش اصلی۱. ساختار (Structure)ما ۴ محصول و ۵ تیم داشتیم. اگر برای هر تیم پروژه جدا درست می‌کردیم، خیلی زود به آشفتگی می‌رسیدیم. راه‌حل:هر محصول = یک پروژههر تیم = یک برد اسکرام + یک برد کانبانیک Custom Field به اسم Team: فقط یک‌بار استوری رو در پروژه محصول خودش ثبت می‌کرد و با انتخاب تیم، همون استوری روی برد تیم مربوطه هم ظاهر می‌شد.۲. دیتا اینتری (Data Entry)اینجا نقطه عطف ما بود. سه لایه داده تعریف کردیم:تخمین با Story Pointثبت روزانه‌ی Log Timeثبت Manual Progress توسط تیم لیداین سه لایه باعث شد بتونیم پیشرفت واقعی رو با پیش‌بینی‌ها مقایسه کنیم.۳. محاسبات و Roadmap Metricsما علاوه بر Sprint، یک مفهوم به اسم Roadmap تعریف کردیم: بازه‌های زمانی بلندتر (مثلاً یک فصل) که روی Epicهای چند تیمی متمرکز می‌شد.اینطوری علاوه بر مدیریت کوتاه‌مدت اسپرینت، تصویر کلان سه‌ماهه هم داشتیم.محاسبات سفارشی با ScriptRunnerبرای این کار هیچ پلاگین آماده‌ای مثل BigPicture یا Advanced Roadmaps استفاده نکردیم. همه‌چیز با اسکریپت‌نویسی ScriptRunner روی خود Jira Issue ساخته شد.ما پروژه ای مجزا داشتیم که توش میتونستیم رود مپ مربوط به هر بازه و تیم رو بسازیم با استفاده از دیتا هی کاستوم شده مربوط به همان تیم و در حقیقت بازه زمانی و ظرفیت تیم. بعد به صورت اتومات محاسبات انجام میشدفرم ایجاد رودمپمحاسبه ظرفیت و Availability تیم‌هایکی از ارزشمندترین بخش‌ها برای ما این بود که بتونیم ظرفیت واقعی تیم‌ها رو هم بر اساس لاگ تایم و داده‌های استوری پوینت اندازه بگیریم. برای همین سه متریک جدید تعریف کردیم:Roadmap Efficient Times: 623.896 → زمان کارآمدی واقعی بر اساس لاگ تایم و پیشرفت کار.Roadmap Optimistic Times: 748.675 → ظرفیت خوش‌بینانه (اگر همه افراد با حداکثر توان کار کنن).Roadmap Pessimistic Times: 539.91 → ظرفیت بدبینانه (اگر وقفه‌ها و کارهای غیرمنتظره زیاد باشه).📊 با این سه شاخص می‌شد خیلی ساده ببینیم:اگر با سرعت معمولی ادامه بدیم، چقدر زمان لازم داریم.اگر تیم در شرایط ایده‌آل کار کنه، زودترین زمان اتمام چقدره.و اگر مشکلات زیادی پیش بیاد، چه تاخیری محتمل خواهد بود.این داده‌ها به Product Ownerها و مدیرها کمک کرد که خیلی واقع‌بینانه‌تر برنامه‌ریزی کنن. مثلاً وقتی یک Epic بزرگ به ۷۴۸ ساعت نیاز داشت ولی ظرفیت بدبینانه تیم فقط ۵۴۰ ساعت بود، تصمیم‌گیری درباره جابجایی اولویت‌ها یا اضافه کردن نیرو خیلی سریع‌تر اتفاق می‌افتاد.متریک‌هایی که محاسبه می‌کردیم:sum of log: 376.72roadmap log: 242.02Average Manual Progress: 34.33Roadmap Manual Progress: 30.28Expected Progress: 1.56Real Progress: 2.578Sum Story Points: 153Logged Story Point: 125SP Progress: 52.525Logged SP Progress: 29.35نمونه داشبورد محاسبه پرفورمنس و میزان پیشرفت رودمپاین مقادیر مستقیم روی Custom Fieldهای Issue ذخیره می‌شدن و بعد روی داشبورد قابل گزارش‌گیری بودن.نمونه اسکریپت (Story Point Progress + Manual Progress Average)import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.issue.MutableIssueimport com.atlassian.jira.bc.issue.search.SearchServiceimport com.atlassian.jira.web.bean.PagerFilter def cfm = ComponentAccessor.customFieldManagerdef searchService = ComponentAccessor.getComponent(SearchService)def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser final String SP_CF_NAME = "Story Points"final String MANUAL_PROGRESS_CF = "Manual Progress"final String OUTPUT_AVG_CF_NAME = "Average Manual Progress"final String OUTPUT_SP_PROGRESS_CF_NAME = "SP Progress" def cfSP = cfm.getCustomFieldObjectByName(SP_CF_NAME)def cfManual = cfm.getCustomFieldObjectByName(MANUAL_PROGRESS_CF)def cfOutputAvg = cfm.getCustomFieldObjectByName(OUTPUT_AVG_CF_NAME)def cfOutputSP = cfm.getCustomFieldObjectByName(OUTPUT_SP_PROGRESS_CF_NAME) def issue = issue as MutableIssue def jql = "project = ${issue.projectObject.key} AND 'Roadmap Num' ~ '${issue.getCustomFieldValue(cfm.getCustomFieldObjectByName("Roadmap Num"))}'"def parseResult = searchService.parseQuery(user, jql)def searchResult = searchService.search(user, parseResult.query, PagerFilter.getUnlimitedFilter()) def issues = searchResult.issues double totalSP = 0double loggedSP = 0double totalManual = 0int countManual = 0 issues.each { i -> def sp = i.getCustomFieldValue(cfSP) as Double ?: 0 totalSP += sp if ((i.getTimeSpent() ?: 0) > 0) loggedSP += sp def mp = i.getCustomFieldValue(cfManual) as Double ?: 0 if (mp > 0) { totalManual += mp countManual++ }} def avgManual = countManual > 0 ? (totalManual / countManual) : 0def spProgress = totalSP > 0 ? (loggedSP / totalSP) * 100 : 0 issue.setCustomFieldValue(cfOutputAvg, avgManual)issue.setCustomFieldValue(cfOutputSP, spProgress) مثال واقعی: توسعه‌ی API پرداختیک Epic در محصول B داشتیم: توسعه‌ی سرویس پرداخت.Backend Team: پیاده‌سازی endpoint /api/v2/payment/transaction (POST + JSON شامل token, amount, callback).Mobile Team: مصرف API در اپ اندروید، طراحی UI موفق/ناموفق و هندلینگ خطا.قبلاً این یعنی چندین تیکت جدا در پروژه‌های مختلف.ولی اینجا با ساختار جدید: یک استوری در پروژه محصول B + Sub-task با Team=Backend و Team=Mobile.📌 نتیجه:PO محصول B یک فیچر کامل رو end-to-end می‌دید.تیم موبایل (که روی همه محصولات سرویس می‌داد) فقط برد خودش رو نگاه می‌کرد و همه کارها جمع بود.داشبورد Roadmap دقیقاً درصد پیشرفت واقعی vs انتظار رو نشون می‌داد.داشبوردهای تحلیلی با Rich Filterآخرین بخش کار ما Visualization بود. فقط محاسبات کافی نبود، باید همه بتونن ببینن و تحلیل کنن.چرا Rich Filter؟فیلترهای دینامیک: Roadmap Num، Sprint، Priority، Project، Status.امکان Drill Down روی هر بُعد.ویجت‌های متنوع برای مقایسه‌ی Story Point و زمان صرف‌شده.نمونه داشبورد (Agent Detail Performance)Story Point per Assignee: سهم هر فرد از Story Pointها. کمک کرد بار کاری متعادل‌تر بشه.Time Spent per Assignee: نشون داد چه کسی واقعاً وقت گذاشته. جلوی mismatch بین تخمین و لاگ گرفته شد.Story Point per Project: سهم تیم‌ها بین محصولات مختلف مشخص شد. POها دیدن چه مقدار از ظرفیت‌شون روی کدوم پروژه مصرف میشه.Filterهای سریع: امکان بررسی فقط High Priority، یا فقط Sprint جاری، یا فقط Roadmap خاص.📊 نتیجه این شد که داده‌ها از سطح «گزارش به مدیریت» بالاتر رفت و تبدیل شد به ابزاری برای تصمیم‌گیری روزانه و مدیریت بار کاری تیم.نتیجه‌گیریبعد از ۶ ماه، این مدل برای ما یک Best Practice واقعی شد:Product-centric projectsTeam-centric boardsScripted Metrics به جای پلاگین‌های سنگینRich Filter Dashboards برای تحلیلو از همه مهم‌تر: تغییر فرهنگ تیمی. دیتا اینتری از یک کار خسته‌کننده تبدیل شد به ابزاری برای شفافیت و مدیریت. هم تیم‌ها راضی بودن، هم POها تصویر کلان داشتن، هم لیدها داده‌ی واقعی برای تصمیم‌گیری داشتن.👉 حالا سؤال من برای شما: توی تیم‌تون چقدر به داده‌ی واقعی متعهدید؟ و آیا حاضرید به جای بحث‌های بی‌پایان تخمین، یک بار برای همیشه ساختار و فرهنگ دیتا اینتری رو درست کنید؟ masoud sajjad masoud sajjad Fri, 29 Aug 2025 19:54:22 +0330