Agile و مدیریت محصول · ۱۳ دقیقه مطالعه · Product Ownerها، Scrum Masterها، مدیران پروژه، Engineering Managerها و رهبرانی که می‌خواهند اثر AI بر delivery را بدون بازی‌دادن metricها بفهمند
Velocity بالا رفته؛ آیا تیم سریع‌تر شده است؟
این مقاله توضیح می‌دهد چرا افزایش velocity بهتنهایی نشانهٔ سریع‌ترشدن تیم نیست و چگونه با کمک baseline، outcome، throughput، rework و معیارهای پایداری، اثر AI بر Agile و مدیریت پروژه را منصفانه بسنجیم.
- Velocity مقدار کار امتیازدهی‌شده را نشان می‌دهد، نه ارزش محصول یا بهرهوری فرد.
- AI میتواند output و velocity را بالا ببرد بدون اینکه outcome بهتر شده باشد.
- تعریف Done، review، تست، امنیت، rework و کار پس از launch را پنهان نکنید.
- Throughput و instability باید کنار هم و در context یک application خوانده شوند.
- Metric وقتی به quota تبدیل شود، رفتار تیم را به سمت بازی‌دادن عدد می‌برد.
- اثر AI را با baseline، outcome، flow، stability و cost در یک workflow مشخص بسنجید.
- AI میتواند evidence را جمع کند؛ تفسیر، capacity و accountability انسانی می‌ماند.
Velocity دقیقاً چه چیزی را می‌گوید؟
Velocity معمولاً مجموع Story Pointهای itemهایی است که تیم در یک Sprint به Definition of Done رسانده است. این عدد اگر با referenceهای ثابت و در یک تیم مشخص استفاده شود، میتواند برای forecast داخلی کمک‌کننده باشد. اما واحد اندازه‌گیری ارزش محصول نیست، زمان دقیق نیست و ابزار مقایسهٔ افراد یا تیم‌های متفاوت هم نیست.
Scrum Guide به‌جای تجویز velocity، بر forecast با توجه به performance گذشته، ظرفیت آینده و Definition of Done تأکید می‌کند. این نگاه مهم است: عدد گذشته برای ساختن یک انتظار احتمالی به‌کار می‌رود، نه برای ساختن quota یا تعهد قطعی. اگر روش sizing، ترکیب تیم، نوع کار یا تعریف Done عوض شود، مقایسهٔ عددهای قبل و بعد باید با احتیاط انجام شود.
AI چرا velocity را سریع بالا می‌برد؟
AI میتواند بخشی از کار تولیدی و هماهنگی را کوتاه کند. مدل ممکن است context را خلاصه کند، draft code یا test بدهد، یک item را به taskهای کوچکتر بشکند یا blocker احتمالی را زودتر نشان دهد. در نتیجه تیم میتواند بعضی کارها را با اصطکاک کمتر به مسیر تحویل ببرد.
اما این افزایش ظرفیت بالقوه، خودبه‌خود به velocity قابل‌اعتماد تبدیل نمی‌شود. اگر تیم به‌خاطر توان جدید، itemهای بیشتری را وارد Sprint کند، verification و integration گلوگاه شوند یا Definition of Done به‌صورت پنهان سبکتر شود، نمودار بالا می‌رود ولی سیستم تحویل سالم‌تر نمی‌شود.
در مستندات رسمی فعلی GitHub، Copilot cloud agent میتواند repository را بررسی کند، plan بسازد، روی branch تغییر ایجاد کند و خروجی را برای review و iteration به pull request برساند. این خبر دربارهٔ سطح جدید automation مهم است، اما خودش نتیجهٔ delivery یک تیم را ثابت نمی‌کند. بین «agent توانایی انجام این مراحل را دارد» و «تیم با کیفیت و outcome بهتر تحویل می‌دهد» باید evidence جداگانه جمع شود.
پنج دلیل که velocity بالا می‌رود اما ارزش نه
پیش از اینکه افزایش velocity را موفقیت اعلام کنیم، این پنج توضیح را بررسی می‌کنم:
این بررسی کمک می‌کند به‌جای سرزنش تیم یا خاموش‌کردن بی‌دلیل AI، محل واقعی تغییر را پیدا کنیم. گاهی automation واقعاً ارزشمند است؛ گاهی فقط کار کم‌ریسک را زیاد می‌کند و کار مهم هنوز در backlog یا review گیر کرده است.
- تغییر مقیاس: تیم بعد از ورود AI itemهای مشابه را کوچکتر امتیاز می‌دهد و عددها دیگر با گذشته هم‌معنا نیستند؛
- جابجایی کار پنهان: تولید code سریع شده اما تست، review، امنیت، migration یا رفع failure در خارج از Sprint ثبت می‌شود؛
- انتخاب کار آسان: برای نشان‌دادن خروجی بیشتر، itemهای کوچک و کم‌ریسک جلو می‌افتند و outcomeهای سخت‌تر عقب می‌مانند؛
- افزایش batch و WIP: خروجی بیشتری تولید می‌شود اما کار نیمه‌تمام، context switching و صف review بیشتر می‌شود؛
- تبدیل automation به خروجی: ticket، draft یا pull request زیاد می‌شود بدون اینکه رفتار کاربر، درآمد، یادگیری یا قابلیت اطمینان بهتر شود.
به‌جای velocity چه چیزی را کنار آن ببینیم؟
یک metric بهتنهایی برای سیستم پیچیده کافی نیست. برای فهم اثر AI، یک صفحهٔ ساده بسازید که delivery، outcome و سلامت سیستم را کنار هم نشان دهد. هدف جمع‌کردن ده‌ها عدد نیست؛ هدف این است که یک عدد صعودی نتواند افت کیفیت یا ارزش را پنهان کند.
DORA در راهنمای رسمی خود metricهای delivery را به دو گروه throughput و instability تقسیم می‌کند. throughput شامل change lead time، deployment frequency و failed deployment recovery time است؛ instability شامل change fail rate و deployment rework rate. این معیارها باید در context یک application یا service و در طول زمان خوانده شوند، نه برای مسابقه میان تیم‌های نامشابه.
- Outcome: آیا مسئلهٔ کاربر، conversion، زمان انجام کار یا معیار کسب‌وکار واقعاً بهتر شده است؟
- Quality: نرخ defect، rollback، failure، شکایت، خطای AI و کار برگشتی چقدر است؟
- Flow: زمان از شروع تا Done، زمان انتظار review، WIP و اندازهٔ batch چه تغییری کرده است؟
- Stability: تغییرهای بیشتری با موفقیت منتشر می‌شوند یا incident و rework هم بالا رفته است؟
- Cost: هزینهٔ token، ابزار، review، زیرساخت، پشتیبانی و نگهداری نسبت به outcome چه وضعی دارد؟
- Learning: تیم سریع‌تر فرضیه را آزمایش و از نتیجه برای تصمیم بعدی استفاده می‌کند یا فقط خروجی بیشتری می‌سازد؟
خبر DORA دربارهٔ metricها چه درسی برای AI دارد؟
راهنمای رسمی DORA که آخرین‌بار در ۵ ژانویهٔ ۲۰۲۶ به‌روزرسانی شده، تأکید می‌کند این metricها باید برای بهبود مستمر استفاده شوند و تبدیل‌شدنشان به هدف میتواند رفتار تیم را منحرف کند. همین منطق دربارهٔ velocity و AI هم صدق می‌کند: وقتی عدد به quota تبدیل شود، تیم راه‌هایی برای بهترکردن عدد پیدا می‌کند، نه الزاماً راه‌هایی برای بهترکردن محصول.
DORA همچنین دربارهٔ یک metric برای همه، مقایسهٔ سیستم‌های ناهمگون، ownership جزیره‌ای و تمرکز افراطی بر اندازه‌گیری هشدار می‌دهد. برای تیم AI، این هشدارها مهم‌تر هم می‌شوند؛ چون نوع کار، سطح ریسک، مقدار review انسانی و هزینهٔ failure بین یک feature ساده و یک workflow تصمیم‌ساز قابل‌مقایسه نیست.
چگونه baseline قبل و بعد از AI بسازیم؟
برای سنجش عادلانه، اول یک بازهٔ قبل از تغییر انتخاب کنید و فقط به میانگین velocity نگاه نکنید. در همان application یا service، زمان delivery، اندازهٔ batch، WIP، نرخ rework، failure و یک یا دو outcome اصلی را ثبت کنید. سپس AI را در یک workflow مشخص و با مرز روشن وارد کنید؛ تغییر هم‌زمان ده ابزار و دو ساختار تیمی، علت را مبهم می‌کند.
بعد از چند چرخه، داده را در همان context مقایسه کنید. اگر velocity بالا رفته، اما change fail rate، deployment rework یا زمان review هم بالا رفته، بخشی از سرعت صرفاً به ریسک منتقل شده است. اگر velocity ثابت مانده ولی lead time و outcome بهتر شده، ممکن است تیم سالم‌تر و مؤثرتر شده باشد. به یک نمودار واحد اجازه ندهید verdict نهایی بدهد.
- تعریف یک workflow و یک application مشخص؛
- ثبت baseline حداقل برای چند Sprint یا چرخهٔ تحویل؛
- ثابت‌نگه‌داشتن تعریف Done و referenceهای sizing تا حد ممکن؛
- تفکیک کار تولیدشده توسط AI از کار کامل‌شده تا production؛
- ثبت review، تست، rework، incident و زمان برگشت؛
- انتخاب outcomeی که به هدف محصول وصل است؛
- بازبینی metricها با تیم و حذف عددهایی که هیچ تصمیمی را تغییر نمی‌دهند.
با velocity بالا چه تصمیم‌هایی نگیریم؟
بالارفتن عدد نباید بهتنهایی باعث افزایش تعهد، کاهش نیروی انسانی، فشرده‌کردن deadline یا مقایسهٔ افراد شود. این تصمیم‌ها به شواهد گسترده‌تری نیاز دارند. AI میتواند توان تیم را افزایش دهد، اما ظرفیت واقعی همچنان با کیفیت، تمرکز، ownership، dependency و مسئولیت پس از انتشار محدود می‌شود.
همچنین نباید هر افت outcome را با افزایش automation پاسخ دهیم. ممکن است مسئله در strategy، discovery، تعریف مسئله، onboarding، pricing یا adoption باشد. اگر مشکل انتخاب کار است، ابزار delivery بیشتر فقط کار اشتباه را سریع‌تر می‌کند.
- تبدیل velocity به KPI فردی یا رتبه‌بندی اعضای تیم؛
- اعلام اینکه AI ظرفیت تیم را دو برابر کرده، بدون تعریف ظرفیت و outcome؛
- کم‌کردن زمان review یا تست برای حفظ نمودار صعودی؛
- مقایسهٔ velocity دو تیم با محصول، ترکیب، ریسک و Definition of Done متفاوت؛
- قبول‌کردن scope بیشتر فقط چون agent میتواند draft آن را بسازد؛
- نسبت‌دادن تغییر نتیجه به AI وقتی چند متغیر دیگر هم‌زمان تغییر کرده‌اند.
اثر AI بر هزینه و مدیریت پروژه
در مدیریت پروژه، افزایش velocity یک سیگنال اقتصادی است اما صورت‌حساب نیست. اگر AI کار اولیه را کم‌هزینه‌تر کند ولی review، زیرساخت، token، امنیت و نگهداری را بالا ببرد، هزینهٔ مالکیت ممکن است بیشتر شود. برای تصمیم بودجه باید build، run، rework و opportunity cost را جدا دید.
این همان جایی است که برآورد پروژه از بحث metric جدا نمی‌ماند. تیمی که فقط Story Point یا velocity را به مشتری گزارش می‌کند، ممکن است میزان واقعی ریسک و کار پس از launch را نشان ندهد. گزارش بهتر می‌گوید چه چیزی تحویل شده، چه outcomeی دیده شده، چه ریسکی باز است و برای مرحلهٔ بعد چه هزینه و ظرفیتی لازم است.
مدل سادهٔ گزارش هفتگی برای تیم کوچک
برای یک تیم کوچک، گزارش خوب میتواند در یک صفحه جا شود. AI میتواند دادهٔ ابزارها را جمع و خلاصه کند، اما تیم باید تفسیر و action را مالک باشد:
اگر velocity زیاد شده ولی outcome یا stability تغییر نکرده، تصمیم هفتهٔ بعد باید پیدا کردن constraint باشد، نه درخواست خروجی بیشتر. یک سؤال خوب از metric این است: «این عدد کدام تصمیم ما را تغییر می‌دهد؟» اگر پاسخ نداریم، احتمالاً فقط dashboard ساخته‌ایم.
- هدف و outcome هفته یا Sprint؛
- کار Doneشده تا production، نه فقط ticket بسته‌شده؛
- یک نشانهٔ flow مانند lead time یا زمان review؛
- یک نشانهٔ stability مانند failure، rollback یا rework؛
- هزینهٔ قابل‌توجه AI، زیرساخت و کار انسانی؛
- یک یادگیری و یک constraint اصلی؛
- یک action مشخص با owner و تاریخ بازبینی.
چک‌لیست تفسیر افزایش velocity
- آیا تعریف Story Point، reference و Definition of Done ثابت مانده است؟
- آیا itemهای بیشتر واقعاً به production و outcome رسیده‌اند؟
- آیا rework، defect، rollback یا زمان review هم‌زمان بالا رفته است؟
- آیا WIP و اندازهٔ batch کوچکتر و قابل‌کنترل‌تر شده‌اند؟
- آیا تیم کار مهم را جلو انداخته یا فقط کار آسانتر را زیاد کرده است؟
- آیا throughput و instability را با هم می‌خوانیم؟
- آیا outcome و feedback کاربر در کنار metric delivery ثبت شده است؟
- آیا هزینهٔ کامل build و run و نگهداری دیده شده است؟
- آیا از metric برای یادگیری استفاده می‌کنیم یا برای فشار و مقایسه؟
- آیا افزایش velocity به یک تصمیم مشخص و قابل‌آزمایش منجر شده است؟
جمع‌بندی
واقعیت عمومی: velocity یک اندازهٔ نسبی برای forecast داخلی است و Scrum Guide تیم را به استفاده از performance گذشته، capacity و Definition of Done برای پیش‌بینی دعوت می‌کند. DORA هم throughput و instability را کنار هم می‌گذارد و دربارهٔ تبدیل metric به هدف، مقایسهٔ نابجا و ownership جزیره‌ای هشدار می‌دهد.
تحلیل من: AI ممکن است مقدار خروجی قابل‌امتیازدهی را بالا ببرد، اما سازمان فقط با خروجی بیشتر موفق نمی‌شود. باید ببینیم آیا تیم سریع‌تر از مسئله به outcome می‌رسد، کیفیت را حفظ می‌کند، هزینهٔ کامل را کنترل می‌کند و از failure یاد می‌گیرد. اگر نه، velocity بالا فقط یک علامت ناقص است.
پیشنهاد حکیم: قبل از هر ادعای افزایش بهرهوری، یک baseline بسازید، یک workflow را جدا کنید و velocity را کنار outcome، flow، stability و cost بخوانید. AI را برای جمع‌آوری و توضیح evidence به‌کار ببرید؛ تفسیر نهایی، تصمیم capacity و مسئولیت محصول را به نمودار واگذار نکنید.
منابع اولیه برای بررسی
Scrum Guide نسخهٔ HTML برای forecast بر اساس performance گذشته، ظرفیت، Definition of Done و اصول empiricism: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.
راهنمای رسمی DORA دربارهٔ پنج metric عملکرد delivery، تفکیک throughput و instability، context هر application و دام‌های metricگذاری: https://dora.dev/guides/dora-metrics/ — آخرین به‌روزرسانی صفحه 2026-01-05 و بررسی‌شده در 2026-09-15.
مستندات رسمی GitHub دربارهٔ Copilot cloud agent برای research، plan، تغییر روی branch و review/iteration از مسیر pull request: https://docs.github.com/en/copilot/concepts/agents/coding-agent — بررسی‌شده در 2026-09-15.
مرز شواهد و تحلیل
تعریف‌های Scrum، چارچوب metricهای DORA و قابلیت‌های اعلام‌شدهٔ GitHub از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند که استفاده از AI برای هر تیم velocity یا outcome را بهتر کند. چارچوب baseline، گزارش هفتگی، چک‌لیست و تحلیل اثر AI بر Agile، مدیریت محصول و هزینهٔ پروژه دیدگاه امین رضا سیدآبادی است و باید با context، ریسک و دادهٔ واقعی همان تیم سنجیده شود.
پرسش‌های متداول
آیا افزایش velocity بعد از استفاده از AI نشانهٔ موفقیت است؟
بهتنهایی نه. باید بررسی کنید کار بیشتری واقعاً به production و outcome رسیده یا فقط itemها کوچکتر، کارها آسانتر یا تعریف Done سبکتر شده است. کیفیت، rework، stability و هزینه را هم کنار velocity ببینید.
آیا velocity معیار بهرهوری اعضای تیم است؟
نه. velocity یک سیگنال نسبی برای forecast همان تیم است و برای رتبه‌بندی افراد یا مقایسهٔ تیم‌های متفاوت مناسب نیست. استفادهٔ فشاری از آن معمولاً اندازه‌گذاری و رفتار تیم را منحرف می‌کند.
برای سنجش اثر AI بر delivery چه metricهایی لازم است؟
یک ترکیب متناسب با context لازم است: outcome محصول، زمان delivery، throughput، نرخ failure و rework، کیفیت، زمان review، WIP و هزینهٔ کامل. DORA نیز throughput و instability را کنار هم و در سطح application یا service پیشنهاد می‌کند.
چطور velocity قبل و بعد از AI را منصفانه مقایسه کنیم؟
یک workflow یا application مشخص انتخاب کنید، baseline چند چرخه بسازید، تعریف Done و referenceها را تا حد ممکن ثابت نگه دارید و تغییرهای هم‌زمان را ثبت کنید. سپس velocity را همراه outcome، lead time، rework و failure مقایسه کنید؛ یک نمودار کافی نیست.
آیا AI میتواند گزارش بهرهوری تیم را خودش تولید کند؟
AI میتواند دادهها را جمع و خلاصه کند، اما انتخاب metric، تفسیر علت، تصمیم دربارهٔ ظرفیت و اقدام اصلاحی باید با تیم و owner انسانی باشد. گزارش خودکار بدون context ممکن است خروجی بیشتر را با ارزش بیشتر اشتباه بگیرد.