تیم از مدل پروژهای به Scrum مهاجرت کرده است. داشبورد قدیمی سه عدد دارد: ۱۲۰ تست اجراشده، ۱۸ نقص و Pass rate برابر ۹۵٪. مدیر میخواهد آنها را حذف کند و بهجایش Velocity، Cycle time و Defect escape بگذارد. اما هیچکس Consumer و Decision هر عدد، تعریف Start/Finish، Population، Window، Source، Baseline یا اثر حذف آن بر گزارش Release را نمیداند. این «Agile Metrics» نیست؛ تعویض برچسب روی یک سیستم اندازهگیری ناشناخته است.
مهاجرت معیارهای تست به Agile یعنی سنجهها، قراردادهای معنایی، دادهها، تصمیمها و مصرفکنندگان فعلی را Inventory کنید؛ برای هر مورد Keep، Adapt، Replace یا Retire را با دلیل انتخاب کنید؛ Future state را از Goal/Question بسازید؛ سنجههای قدیم و جدید را در Dual-run مقایسه کنید؛ Break/Bridge را ثبت و Cutover را با Rollback انجام دهید. خروجی، «فهرست بهترین KPIهای Agile» نیست؛ یک Measurement system قابلردیابی و اصلاحپذیر است.
پاسخ کوتاه: معیارها را یکشبه عوض نکنید
- Trigger، Scope، Decision Authority و تاریخ احتمالی Cutover را ثبت کنید.
- Metric، گزارش، Alert، Target، Consumer، Source و استفادهٔ واقعی را Inventory کنید.
- هر سنجه را با Keep، Adapt، Replace، Retire یا Investigate طبقهبندی کنید.
- Future state را از Objective/Question/Decision بسازید، نه از فهرست آمادهٔ Agile.
- Semantic contract، Event/Identity/Data mapping و Success/Guardrail را نسخهدار کنید.
- Old/New را در Shadow و Dual-run روی Snapshotهای ثابت مقایسه کنید.
- Comparable، Bridged، Broken یا Unknown بودن تاریخچه را صریح اعلام کنید.
- Cutover را Rehearse کنید؛ Owner، Communication، Rollback و Correction داشته باشید.
- منبع قدیمی را پس از تثبیت بازنشسته کنید، اما تاریخچه و Decision provenance را پاک نکنید.
Intent و کلیدواژههای این راهنما
| جزء | انتخاب |
|---|---|
| Intent اصلی | اطلاعاتی/اجرایی؛ بازطراحی و مهاجرت سیستم سنجش QA هنگام Agile transformation |
| کلمهٔ کلیدی اصلی | معیارهای تست چابک |
| کلیدواژههای فرعی | Agile Testing Metrics، معیارهای QA در Agile، مهاجرت KPI تست، Flow Metrics، Velocity و کیفیت |
| لانگتیل | تفاوت معیارهای تست سنتی و چابک، چگونه KPIهای QA را به Agile مهاجرت دهیم، جایگزین تعداد باگ در Agile، Cutover داشبورد QA، Dual-run متریک |
| پاسخ کوتاه | روش سنجش را با Workflow و Decision جدید هممعنا کنید؛ Metric قدیمی را صرفاً با Metric مد روز عوض نکنید. |
مالکیت این مقاله و مرز با صفحات دیگر
این صفحه مالک QA Measurement Migration است: Current-state Inventory → Consumer/Decision map → Keep/Adapt/Replace/Retire → Future-state contracts → Data mapping → Dual-run/Bridge → Cutover/Rollback → Retirement/Correction. فهرست و قرارداد سنجهها در راهنمای متریکهای تست، انتخاب KPI در KPI Governance و خواندن Signal سری زمانی در تحلیل روند معیارهای تست مالک مستقل دارند.
مقالهٔ تلههای جمعآوری و تفسیر Metric خطاهای Measurement را بررسی میکند؛ بهبود فرایند تست از Chaos تا Flow خود Workflow را تثبیت میکند؛ بهبود مستمر QA Experiment را اجرا میکند و ارزیابی اثربخشی QA ادعای Contribution را میسنجد. Migration هیچکدام را جایگزین نمیکند.
دوگانهٔ «سنتی بد، Agile خوب» را کنار بگذارید
Waterfall همیشه به معنای تست فقط در انتهای پروژه نیست و Agile نیز تضمین نمیکند Feedback سریع، کیفیت بالا یا همکاری واقعی دارید. یک Metric قدیمی ممکن است برای Audit، قرارداد، Support یا Trend بلندمدت ضروری باشد؛ یک Flow metric تازه نیز با Start/Finish مبهم بیمعناست. مسئله قدمت عدد نیست؛ Fitness آن برای Decision فعلی است.
Agile یک کاتالوگ KPI اجباری نیست
اصول Agile Manifesto بر تحویل پیوستهٔ ارزش، نرمافزار کارا بهعنوان Measure اصلی پیشرفت، توسعهٔ پایدار، تعالی فنی و بازاندیشی منظم تأکید میکند؛ Velocity، Defect escape، NPS یا Automation ratio را بهعنوان KPI اجباری تجویز نمیکند. این اصول جهت میدهند، اما Metric Contract سازمان شما نیستند.
Scrum نیز Velocity را الزام نمیکند
Scrum Guide 2020 Scrum را بر Empiricism و Lean thinking، Transparency، Inspection و Adaptation بنا میکند و Product/Sprint Goal و Increment را تعریف میکند. Velocity جزء تعریف Scrum نیست. تیم میتواند برای Forecast داخلی از Estimate history استفاده کند، اما نام آن را بهرهوری، کیفیت یا KPI مقایسهٔ تیمها نگذارد.
Kanban Flow Metrics به Definition of Workflow وابستهاند
Kanban Guide مه ۲۰۲۵ WIP، Throughput، Work Item Age و Cycle Time را حداقل Flow metrics میداند، اما آنها را به Definition of Workflow، Work item و نقاط Started/Finished متصل میکند. کپیکردن «Cycle time» بدون این قرارداد، کاربرد Kanban نیست. خود راهنما نیز میگوید این Metricها بدون کمک به Practiceهای Kanban بیمعنا هستند.
SPACE را Scorecard آمادهٔ QA ندانید
پژوهش SPACE دربارهٔ Developer Productivity نشان میدهد Productivity را نمیتوان با یک Metric یا Dimension سنجید. این بینش برای جلوگیری از Activity-score مفید است، اما پنج بُعد SPACE فهرست اجباری KPI تست یا مجوز امتیازدهی افراد نیست.
چارچوب را با Goal سازمان انتخاب کنید
پژوهش DORA ۲۰۲۵ دربارهٔ Measurement Frameworks بر تناسب چارچوب با اهداف سازمانی و Goal-first بودن تأکید دارد. DORA، SPACE، GQM یا Flow میتوانند Lens بدهند؛ هیچکدام را بدون سؤال، Context و Contract به «داشبورد استاندارد QA» تبدیل نکنید.
چه چیزی واقعاً در Migration جابهجا میشود؟
| لایه | نمونهٔ تغییر | ریسک پنهان |
|---|---|---|
| Decision | گزارش Completion پروژه → مدیریت Flow/ریسک روزانه | Consumer قدیمی هنوز گزارش میخواهد |
| Semantic | Test cycle → Work item cycle | Start/Finish و Unit متفاوتاند |
| Data | Spreadsheet snapshot → Event stream | Duplicate/late/missing event |
| Portfolio | Activity count → Outcome/Flow/Guardrail | حذف Evidence لازم یا افزودن Vanity metric |
| Action | گزارش فصلی → Alert/Review پیوسته | Threshold و Authority نامشخص |
| Governance | مالک ابزار → Owner/Steward/Authority چندنقشی | تغییر خاموش Contract |
| History | یک Trend طولانی → Series break/Bridge | مقایسهٔ جعلی قبل/بعد |
QA Measurement Migration Loop
Trigger / Mandate / Scope / Decision → current Metric + Consumer + Action inventory → semantic / data / behavior / risk audit → KEEP | ADAPT | REPLACE | RETIRE | INVESTIGATE → future Goal / Question / Portfolio / Contract → source + identity + event + transform mapping → backfill assessment + frozen validation snapshots → SHADOW + DUAL_RUN + discrepancy triage → COMPARABLE | BRIDGED | BREAK | UNKNOWN → cutover rehearsal + gate + communication → CUTOVER | ROLLBACK | HOLD → stabilization + legacy retirement + correction
Trigger مهاجرت را مشخص کنید
«Agile شدیم» Trigger کافی نیست. Trigger ممکن است تغییر Workflow، محصول/Value stream، Consumer/Decision، ابزار/Schema، الزام قراردادی، رفتار Gaming، ادغام تیمها یا ناتوانی Metric در پاسخ به سؤال باشد. Trigger مرز Scope و فوریت را تعیین میکند؛ بدون آن، پروژه به تعویض Dashboard گسترش مییابد.
Migration Charter را پیش از تغییر بسازید
migration_id / revision / supersedes / status / as_of trigger / problem / scope / out_of_scope current_system_ref / target_operating_model_ref decisions / consumers / authority / due legacy_inventory_ref / future_portfolio_ref data_sources / dependencies / downstream_consumers dual_run_window / cutover_gate / rollback_triggers history_policy / retention / privacy_access owners / communication / training / support risks / guardrails / not_claimed / correction_policy
Current State را از واقعیت بسازید، نه از Dashboard
Dashboard فقط View است. Inventory باید Query، Export، Sheet، ایمیل دستی، اسلاید، Alert، API، Target، Bonus، Gate و تصمیمهای خارج از ابزار را کشف کند. با Consumerها مصاحبه کنید: این عدد را کجا میبینند؟ اگر فردا حذف شود چه تصمیمی میشکند؟ آیا واقعاً استفاده میشود یا فقط تولید میشود؟
قالب Legacy Metric Inventory
legacy_metric_id / label / aliases / version purpose / question / consumer / decision / action owner / source / query / transform / refresh entity / population / inclusion / exclusion / unit event_time / window / denominator / attempt_policy baseline / target / threshold / alert / dashboard downstream_report / automation / contract / retention known_issues / gaming / privacy / criticality last_used / proposed_disposition / evidence / approver
Metric Lineage و Consumer Graph رسم کنید
یک فیلد `pass_rate` ممکن است از سه Query با Attempt policy متفاوت وارد Dashboard، گزارش Closure، Alert و Bonus شود. Source→Transform→Metric→View→Claim→Decision→Action را رسم کنید. حذف Node بدون شناخت Edge، Silent failure میسازد. Consumer بدون Owner را `ORPHAN` و استفادهٔ ناشناخته را `UNKNOWN` ثبت کنید.
تصمیم پنجحالته: Keep، Adapt، Replace، Retire، Investigate
| Disposition | زمان مناسب | تعهد |
|---|---|---|
| KEEP | Decision و Semantic و Data همچنان Fit هستند | Contract/Owner/Review را تثبیت کنید |
| ADAPT | Question پابرجاست اما Scope/روش تغییر میکند | Revision و Bridge/Break لازم است |
| REPLACE | Measure جدید همان Decision را بهتر پشتیبانی میکند | Dual-run و Consumer acceptance |
| RETIRE | Decision/Consumer حذف یا Harm بیشتر از Value است | Dependency check، archive و sunset |
| INVESTIGATE | مصرف، معنا یا کیفیت داده نامعلوم است | تا رفع Unknown، حذف یا Cutover نکنید |
قدیمی بودن دلیل Retire نیست
یک سنجهٔ قدیمی ممکن است برای قرارداد مشتری، Audit، SLO، Capacity یا تحلیل تاریخی ضروری باشد. در مقابل، یک Metric تازه ممکن است Consumer یا Action نداشته باشد. Disposition را با Fitness، Cost، Harm، Dependency و Decision evidence توجیه کنید، نه با واژههای Legacy/Modern.
Future State را از Goal و Question طراحی کنید
ابتدا بپرسید: برای کدام Objective و تصمیم چه باید بدانیم؟ سپس Candidate measure انتخاب کنید. «به Agile رفتیم، پس Velocity لازم است» Metric-first است. شاید سؤال واقعی «کدام Evidence بیش از SLE منتظر است؟»، «چه Riskی بدون Oracle مانده؟» یا «کدام Slice پس از Release آسیب دیده؟» باشد.
Portfolio آینده را متوازن اما کوچک نگه دارید
- Outcome: نتیجهٔ مورد نظر Stakeholder یا Product در Scope مشخص؛
- Flow/Predictability: حرکت Work/Evidence در Workflow تعریفشده؛
- Quality/Risk Evidence: شواهد محدود دربارهٔ Product/Service risk؛
- Capability/Feedback: توان ساخت Feedback معتبر در زمان مناسب؛
- Guardrail/Harm: پیامد ناخواسته، Gaming، امنیت، دسترسپذیری یا فشار؛
- Data health: Completeness، Freshness، Duplicate و lineage؛
- Context/Diagnostic: توضیح Investigation، نه KPI دائمی.
Activity را با Outcome جایگزین نکنید؛ رابطه را بسازید
تعداد Test case و Defect فعالیت/Observation هستند؛ Cycle time و Throughput نیز Outcome کسبوکار نیستند. Metric جدید فقط بهخاطر Flow بودن «بهتر» نیست. Theory/Hypothesis و Guardrail لازم است تا نشان دهد تغییر چه مکانیسمی دارد و چه چیزی را ادعا نمیکند.
Velocity: Forecast محلی، نه امتیاز عملکرد
Story point مقیاس قراردادی همان تیم است و با تغییر Refinement، Composition، Definition of Done، Item split یا Scale جابهجا میشود. Velocity میتواند ورودی Forecast داخلی باشد؛ مقایسهٔ تیمها، Target افزایشی، تبدیل به ساعت یا نسبتدادن مستقیم به Value/Quality آن را مستعد Gaming میکند. در Migration، استفادهٔ قدیم/جدید و ممنوعیتهای آن را صریح بنویسید.
Burndown کیفیت یا ارزش را نشان نمیدهد
Burndown کار باقیمانده طبق یک Scope/Estimate را نمایش میدهد. خط زیبا نمیگوید Increment قابلاستفاده، Risk پوشش داده، Goal محقق یا Outcome ایجاد شده است. تغییر Scope، Split و Estimate هم شکل نمودار را عوض میکند. اگر نگه میدارید، Claim آن را به Tracking محدود کنید.
Cycle Time بدون Start/Finish قرارداد ندارد
Start میتواند Selected، In Development، Ready for Test یا First Evidence باشد؛ Finish میتواند Code complete، Done، Accepted یا Released باشد. Item type، blocked time، reopened item، cancellation و timezone نیز نتیجه را تغییر میدهند. «کاهش Cycle time» بدون ثابتبودن این معنا، Improvement نیست.
WIP و Work Item Age به Identity سالم نیاز دارند
اگر یک Risk، Story، Bug و Test request در یک Item ادغام یا چندبار Clone شوند، WIP جعلی میشود. Work Item Age نیز با Reset کردن Start هنگام انتقال Board پاک میشود. Stable identity، State transition history و Definition of Workflow را پیش از مهاجرت Flow metric برقرار کنید.
Throughput اندازهٔ Value نیست
Throughput تعداد Item تمامشده در زمان است، نه مجموع ارزش، پیچیدگی یا کیفیت. Split کردن کار میتواند آن را بالا ببرد. برای Forecast Flow مفید است، اما باید Item type/Mix و policy ثابت یا قابلمشاهده باشد. Value evidence و Outcome را جدا نگه دارید.
Defect Count و Escape را با انتقال State اصلاح کنید
Bug count به Opportunity، Detection channel، Duplicate policy، Severity، Release exposure و Reporting behavior وابسته است. Escape فقط وقتی معنا دارد که Defect، Detection boundary، Population/Denominator و Window تعریف شوند. کاهش آن بهتنهایی اثربخشی QA یا کیفیت بالاتر را ثابت نمیکند؛ گزارش کمتر، Exposure کمتر یا تغییر Taxonomy میتواند عامل باشد.
Defect Density را بر Story Point تقسیم نکنید
Story point Size فنی قابلمقایسهٔ محصول نیست. چگالی نقص فقط با Defect/Size/Observation و Comparability contracts معتبر است. تغییر KLOC، Function point، Module یا Story point Series break میسازد. Metric را بهخاطر داشتن یک Denominator «نرمالشده» ننامید.
Coverage Evidence است، نه Risk score
Line/Branch/Requirement/Risk/State coverage Universe و Denominator متفاوت دارند. Coverage پایین بهتنهایی «ریسک جدی» و Coverage بالا «اطمینان» نیست. اگر Coverage را منتقل میکنید، Contract و Claim آن را حفظ کنید؛ برای مرزهای دقیق از راهنمای Coverage Claim استفاده کنید.
Automation Ratio بلوغ نیست
نسبت Automated/Manual به تعریف Check، Scope و Counting unit وابسته است؛ بالا رفتن آن میتواند از افزودن Checkهای کمارزش یا حذف Exploration بیاید. Candidate selection، Signal، Flake، Maintenance، Cost و Evidence fitness مهمتر از درصد خاماند. آن را Target سازمانی یا جایگزین قضاوت انسانی نکنید.
NPS و رضایت «معیار نهایی QA» نیستند
رضایت به قیمت، Support، Brand، انتظار، Sample و Self-selection وابسته است. QA فقط یکی از Contributorهای احتمالی است. Feedback مستقیم ارزشمند است، اما به Construct/Population/Question مشخص نیاز دارد. عدد رضایت را حقیقت نهایی Product یا اثربخشی تست ننامید.
Semantic Diff را Field-by-field ثبت کنید
semantic_mapping_id / old_metric_ref / new_metric_ref same_question / same_entity / same_population / same_unit old_start_finish / new_start_finish old_window / new_window / old_attempt / new_attempt old_inclusion_exclusion / new_inclusion_exclusion old_source_transform / new_source_transform known_delta / expected_direction / tolerance comparability_class / bridge_method / approver
Identity و Event Contract را قبل از Backfill ببندید
Project ID، Sprint ID، Work item، Test case، Execution، Attempt، Defect، Build، Release و Deployment را یکی نگیرید. Event باید event_id، entity_id/type، state_from/to، event_time، ingested_at، source، schema_version و correction link داشته باشد. Late، duplicate، reordered و missing event Policy لازم دارد.
Backfill همیشه ممکن یا صادقانه نیست
Snapshotهای قدیمی ممکن است transition history، Attempt، Deleted item یا exact timestamp نداشته باشند. پرکردن Start با Created time یا Missing با صفر، تاریخ جعلی میسازد. Backfill را `FULL`، `PARTIAL`، `MODELLED` یا `NOT_POSSIBLE` طبقهبندی و دورهٔ غیرقابلمقایسه را علامتگذاری کنید.
Frozen Validation Pack بسازید
برای تست Transform، Dataset مصنوعی با caseهای Normal، Cancelled، Reopened، Duplicate، Late، Missing، Out-of-order، DST/timezone و Schema-version بسازید. Expected output مستقل از Query تولیدی باشد. دادهٔ زندهٔ متغیر Oracle خوبی برای Migration نیست.
Dual-run چیست؟
در Dual-run، Pipeline قدیم و جدید برای Window محدود روی Populationهای تا حد ممکن همراستا اجرا میشوند. هدف برابرشدن عددها نیست؛ توضیحپذیری Delta و Fitness تصمیم است. برای Replace با Semantic متفاوت، اختلاف انتظار میرود. Dual-run باید هزینه، Window، Sample، Acceptance، Triage و Stop داشته باشد.
dual_run_id / old_revision / new_revision / snapshot_ids window / population_alignment / exclusions expected_delta / tolerance_basis / discrepancy_taxonomy data_health / owner / daily_review acceptance / stop / extension / evidence_pack
هر اختلافی Defect نیست
| کلاس Delta | مثال | اقدام |
|---|---|---|
| EXPECTED_SEMANTIC | Finish قدیم=Test complete، جدید=Done | Bridge/Break و توضیح Consumer |
| DATA_QUALITY | Event گمشده یا Duplicate | Fix source/ingestion و Replay |
| TRANSFORM_DEFECT | Timezone یا Attempt filter اشتباه | Fix، rerun، Correction |
| SCOPE_MISMATCH | Bug با Story در Population مخلوط است | Align/Separate |
| LEGACY_DEFECT | Query قدیم Cancelled را Count میکرد | اثر Claimهای گذشته را بررسی کنید |
| UNKNOWN | Provenance کافی نیست | Hold؛ اختلاف را صفر نکنید |
Comparable، Bridged، Break و Unknown
- COMPARABLE: Semantic/Data هممعنا و اختلاف در حد ازپیشتوجیهشده است.
- BRIDGED: رابطهٔ محدود در دورهٔ همپوشان برآورد و دامنهٔ کاربرد آن ثبت شده است.
- SERIES_BREAK: مقایسهٔ مستقیم گمراهکننده است؛ خط مرزی نمایش دهید.
- UNKNOWN: Evidence برای یکی از سه ادعای بالا کافی نیست.
Bridge به معنای تبدیل جهانی نیست
رابطهٔ Old/New در یک تیم، Item mix و Window ممکن است جای دیگر معتبر نباشد. Bridge باید Method، Overlap period، Residual/uncertainty، Population و Expiry داشته باشد. Story point را به ساعت، Velocity را به Throughput یا Test-cycle time را به Delivery cycle time با ضریب ثابت تبدیل نکنید.
Baseline را وسط Migration بازنویسی نکنید
Baseline قدیم، Baseline جدید و Bridge period سه Snapshot جدا هستند. اگر Semantic تغییر کرده، Trend قبلی را با فرمول تازه Restate نکنید مگر Raw data، روش قابلدفاع و برچسب Restated دارید. Original series را نگه دارید و اثر تصمیمهای گذشته را حفظ کنید.
Target و Threshold نیز مهاجرت میکنند
Target قدیم را به مقیاس جدید کپی نکنید. ابتدا Baseline و رفتار Metric جدید را در Shadow ببینید، Cost/Harm و Action را تعیین و Target/Threshold را با Revision تصویب کنید. Control limit، SLE، Target و Alert threshold مفاهیم متفاوتاند.
Dashboard، Alert و Report را همزمان ممیزی کنید
Cutover Data بدون Cutover View ممکن است Label قدیمی را روی Semantic جدید نشان دهد. Title، Definition tooltip، As-of، Population، Unit، Break marker، Unknown state، Accessible table، Export و API contract را بررسی کنید. Alert باید Trigger، Owner، SLA و Action جدید داشته باشد.
Automated decisionهای پاییندستی را پیدا کنید
Metric ممکن است Release gate، Pager، Bonus، Capacity forecast یا Vendor report را تغذیه کند. تغییر Field/Unit یا Null semantics میتواند تصمیم خودکار را بیصدا عوض کند. Contract test، Consumer acknowledgment و Kill switch برای استفادههای پرریسک لازم است.
Cutover Gate چه چیزی را بررسی میکند؟
- Migration Charter و Dispositionها Approved-for-cutover هستند؛
- Metric/Data/View/Alert contract نسخهدار و Ownerدار است؛
- Frozen pack و Dual-run بدون Finding بحرانی باز اجرا شدهاند؛
- Deltaهای باقیمانده Disposition و Consumer impact دارند؛
- Comparability/Bridge/Break در همهٔ Viewها آشکار است؛
- Target/Threshold/Action جدید تصویب یا عمداً غیرفعال است؛
- Consumerها Acknowledge و Training/Support آمادهاند؛
- Backup، Rollback trigger، Kill switch و On-call آماده است؛
- Privacy/Access/Retention و Data health Gate پاس شدهاند؛
- Not claimed و تاریخ Stabilization review ثبت شده است.
Cutover موفق یعنی Pipeline عوض شده، نه کیفیت بهتر شده
`CUTOVER_COMPLETED` فقط میگوید Producer/Consumer طبق برنامه به نسخهٔ جدید منتقل شدهاند. نه Improvement، نه Agile maturity، نه Product quality و نه ارزش مشتری را ثابت میکند. این ادعاها به Evidence و ارزیابی مستقل نیاز دارند.
Rollback را قبل از Cutover تمرین کنید
Rollback باید Version، Data write، Cache، Dashboard، Alert، Consumer API و Decision log را پوشش دهد. مشخص کنید چه چیزی برگشتپذیر نیست—مثلاً تصمیمی که بر Metric غلط گرفته شده—و چگونه Correction/Notification میشود. «Query قدیم هنوز هست» Runbook Rollback نیست.
rollback_id / trigger / authority / max_time producer_version / consumer_version / data_snapshot disable_new_alerts / restore_old_view / replay_policy decision_freeze / notification / validation / closure irreversible_effects / correction_links
Stabilization Window پس از Cutover
پس از Cutover، Data freshness/completeness، Query cost، Alert noise، Consumer confusion، Gaming، Unknown rate و Action quality را پایش کنید. Legacy pipeline را فوراً حذف نکنید، اما دو Truth دائمی هم نسازید. تاریخ Exit از Stabilization و شرط Extension/Abort روشن باشد.
Retirement یعنی Sunset کنترلشده
Producer قدیم را read-only کنید، Write/refresh را متوقف، API/View را Deprecate، Consumer باقیمانده را مسدود یا Exception کنید و Archive/Retention را اعمال کنید. Definition، Query، Revision، History، Decisions و Correction chain را نگه دارید. پاککردن تاریخچه شفافیت نمیسازد.
Communication فقط اعلام Dashboard جدید نیست
| مخاطب | باید بداند | Acknowledgment |
|---|---|---|
| تیم Delivery/QA | Semantic، Use/Non-use، Gaming، Action | Scenario review |
| مدیر/Portfolio | Series break، Target، محدودیت Forecast | Decision receipt |
| Data/Platform | Schema، SLA، lineage، replay، cost | Contract acceptance |
| Audit/Customer | Continuity، Retention، Report change | Formal sign-off if required |
| Support/On-call | Failure mode، rollback، escalation | Rehearsal evidence |
Metric برای امتیازدهی افراد نیست
Velocity، Throughput، Defect count، Cycle time، Coverage و Automation ratio زمینهٔ سیستمی دارند. اتصال آنها به Bonus، Ranking، Headcount یا فشار فردی رفتار را عوض و Migration evidence را آلوده میکند. `people_scoring=false`، unit of analysis، use limitation و Countermetric سلامت تیم را در Charter ثبت کنید.
Privacy و Security در Measurement Migration
Join کردن Git، Ticket، Test، Chat و HR میتواند نظارت فردی و Re-identification بسازد. Purpose limitation، حداقل Field، Aggregation، Pseudonymization، least privilege، retention/deletion، export control و Audit log لازم است. دادهٔ قدیم را فقط چون «برای Trend خوب است» نامحدود نگه ندارید.
Correction پس از کشف خطای Migration
correction_id / discovered_at / owner affected_metric_revisions / windows / views / exports affected_claims / alerts / decisions / consumers cause_class / corrected_values / confidence supersedes / notification / replay / remediation rollback_or_continue / revalidation / closure
آزمایش اجرایی: سه عدد قدیمی و Cutover فوری
Fixture زیر کاملاً ساختگی و آفلاین است. Checker سطحی سه Metric موجود و برچسب `AGILE_CUTOVER_READY` را میبیند. ممیزی Migration دارای ۶۲ Rule است؛ ۶۱ جزء مهاجرت غایباند و Rule آخر People scoring را منع میکند. چون false است، نسخهٔ خام دقیقاً ۶۱ Finding میگیرد. Rule count Benchmark یا مدل بلوغ نیست.
const draft = {
legacy_dashboard: { executed_tests: 120, defects: 18, pass_rate: 95 },
proposed: ["velocity", "cycle_time", "defect_escape"],
declared_status: "AGILE_CUTOVER_READY",
people_scoring: false
};
const present = (v) =>
v !== undefined && v !== null &&
!(typeof v === "string" && v.trim() === "") &&
!(Array.isArray(v) && v.length === 0);
const rules = [
["MM-01 migration_id", x => present(x.migration_id)],
["MM-02 revision", x => present(x.revision)],
["MM-03 supersedes", x => present(x.supersedes)],
["MM-04 as_of", x => present(x.as_of)],
["MM-05 trigger", x => present(x.trigger)],
["MM-06 problem", x => present(x.problem)],
["MM-07 scope", x => present(x.scope)],
["MM-08 out_of_scope", x => present(x.out_of_scope)],
["MM-09 current_system_ref", x => present(x.current_system_ref)],
["MM-10 target_model_ref", x => present(x.target_model_ref)],
["MM-11 decisions", x => present(x.decisions)],
["MM-12 consumers", x => present(x.consumers)],
["MM-13 authority", x => present(x.authority)],
["MM-14 due", x => present(x.due)],
["MM-15 legacy_inventory", x => present(x.legacy_inventory)],
["MM-16 metric_lineage", x => present(x.metric_lineage)],
["MM-17 consumer_graph", x => present(x.consumer_graph)],
["MM-18 dispositions", x => present(x.dispositions)],
["MM-19 disposition_evidence", x => present(x.disposition_evidence)],
["MM-20 future_goals", x => present(x.future_goals)],
["MM-21 future_questions", x => present(x.future_questions)],
["MM-22 future_portfolio", x => present(x.future_portfolio)],
["MM-23 metric_contracts", x => present(x.metric_contracts)],
["MM-24 semantic_mappings", x => present(x.semantic_mappings)],
["MM-25 entity_identity", x => present(x.entity_identity)],
["MM-26 workflow_definition", x => present(x.workflow_definition)],
["MM-27 start_finish", x => present(x.start_finish)],
["MM-28 population_windows", x => present(x.population_windows)],
["MM-29 attempt_policy", x => present(x.attempt_policy)],
["MM-30 event_contract", x => present(x.event_contract)],
["MM-31 source_mapping", x => present(x.source_mapping)],
["MM-32 transform_versions", x => present(x.transform_versions)],
["MM-33 data_quality", x => present(x.data_quality)],
["MM-34 backfill_policy", x => present(x.backfill_policy)],
["MM-35 validation_pack", x => present(x.validation_pack)],
["MM-36 shadow_plan", x => present(x.shadow_plan)],
["MM-37 dual_run", x => present(x.dual_run)],
["MM-38 discrepancy_taxonomy", x => present(x.discrepancy_taxonomy)],
["MM-39 discrepancy_owner", x => present(x.discrepancy_owner)],
["MM-40 comparability_class", x => present(x.comparability_class)],
["MM-41 bridge_or_break", x => present(x.bridge_or_break)],
["MM-42 baseline_policy", x => present(x.baseline_policy)],
["MM-43 target_threshold_policy", x => present(x.target_threshold_policy)],
["MM-44 downstream_contracts", x => present(x.downstream_contracts)],
["MM-45 dashboard_alerts", x => present(x.dashboard_alerts)],
["MM-46 consumer_ack", x => present(x.consumer_ack)],
["MM-47 cutover_gate", x => present(x.cutover_gate)],
["MM-48 rehearsal", x => present(x.rehearsal)],
["MM-49 rollback_plan", x => present(x.rollback_plan)],
["MM-50 rollback_triggers", x => present(x.rollback_triggers)],
["MM-51 kill_switch", x => present(x.kill_switch)],
["MM-52 communication", x => present(x.communication)],
["MM-53 training_support", x => present(x.training_support)],
["MM-54 stabilization", x => present(x.stabilization)],
["MM-55 retirement", x => present(x.retirement)],
["MM-56 history_retention", x => present(x.history_retention)],
["MM-57 privacy_access", x => present(x.privacy_access)],
["MM-58 owners", x => present(x.owners)],
["MM-59 guardrails", x => present(x.guardrails)],
["MM-60 not_claimed", x => present(x.not_claimed)],
["MM-61 correction_policy", x => present(x.correction_policy)],
["MM-62 people_scoring_prohibited", x => x.people_scoring !== true]
];
const findings = (x) => rules.filter(([, ok]) => !ok(x)).map(([id]) => id);
console.log("SUPERFICIAL", Object.keys(draft.legacy_dashboard).length, draft.declared_status);
console.log("MIGRATION", findings(draft).length ? "HOLD" : "READY", findings(draft).length);
const corrected = {
migration_id: "SYN-MM-042", revision: "v1", supersedes: "none:first-revision",
as_of: "2026-08-13T10:00:00Z", trigger: "fictional workflow change",
problem: "legacy measures no longer answer bounded decisions", scope: "synthetic checkout evidence flow",
out_of_scope: ["real organization", "production", "productivity score"],
current_system_ref: "SYS-SYN-LEGACY-v1", target_model_ref: "MODEL-SYN-FLOW-v1",
decisions: ["which evidence item needs investigation?"], consumers: ["ROLE-SYN-QA", "ROLE-SYN-DECISION"],
authority: "ROLE-MIGRATION-AUTHORITY", due: "2026-09-30T10:00:00Z",
legacy_inventory: "INV-SYN-MM-042-v1", metric_lineage: "LINEAGE-SYN-v1",
consumer_graph: "GRAPH-SYN-v1", dispositions: ["KEEP", "ADAPT", "REPLACE", "RETIRE", "INVESTIGATE"],
disposition_evidence: "bounded decision/fitness/cost/harm rationale",
future_goals: ["timely decision evidence"], future_questions: ["where is evidence waiting?", "is data fit?"],
future_portfolio: ["outcome", "flow", "guardrail", "data_health"], metric_contracts: "REG-SYN-MM-v1",
semantic_mappings: "MAP-SYN-MM-v1", entity_identity: "stable fake Work/Evidence/Run/Build IDs",
workflow_definition: "DOW-SYN-v1", start_finish: "accepted-for-evidence to decision-ready",
population_windows: "fictional evidence items; UTC weekly snapshot", attempt_policy: "all attempts retained; latest not substituted",
event_contract: "EVT-SYN-v1 event/ingest/schema/correction", source_mapping: "SOURCE-MAP-SYN-v1",
transform_versions: ["legacy-v1", "candidate-v1"], data_quality: "freshness/completeness/duplicate/order gates",
backfill_policy: "PARTIAL labelled; no missing-as-zero", validation_pack: "PACK-SYN-normal-late-duplicate-reopen-v1",
shadow_plan: "30d; no gate/reward", dual_run: "DUAL-SYN-v1 aligned frozen snapshots",
discrepancy_taxonomy: ["EXPECTED_SEMANTIC", "DATA_QUALITY", "TRANSFORM_DEFECT", "SCOPE_MISMATCH", "UNKNOWN"],
discrepancy_owner: "ROLE-DATA-STEWARD", comparability_class: "SERIES_BREAK with bounded overlap",
bridge_or_break: "visible break; no universal conversion", baseline_policy: "old/new/overlap snapshots separate",
target_threshold_policy: "disabled until shadow review", downstream_contracts: "CONSUMER-CONTRACT-SYN-v1",
dashboard_alerts: "new labels/as-of/break/unknown; alerts disabled in shadow", consumer_ack: "ACK-SYN-v1",
cutover_gate: "GATE-SYN-MM-v1", rehearsal: "REHEARSAL-SYN-v1 restore/read/alert tests",
rollback_plan: "ROLLBACK-SYN-v1", rollback_triggers: ["data gate fail", "unknown critical consumer", "harm"],
kill_switch: "disable new producer/view/alerts", communication: "role-specific change and break notice",
training_support: "scenario walkthrough plus support owner", stabilization: "14d data/consumer/action review",
retirement: "read-only then sunset with exceptions", history_retention: "preserve versions/claims/decisions per fictional policy",
privacy_access: "synthetic only; aggregate; least privilege; expiry", owners: ["migration", "metric", "data", "consumer", "decision"],
guardrails: ["unknown rate", "alert noise", "privacy", "team health"],
not_claimed: ["Agile maturity", "product quality", "improvement", "productivity", "causality"],
correction_policy: "supersede and notify affected consumers/claims/decisions; no silent edit",
people_scoring: false
};
const correctedFindings = findings(corrected);
console.log("CORRECTED", correctedFindings.length ? "HOLD" : "READY_FOR_MEASUREMENT_MIGRATION_REVIEW", correctedFindings.length);خروجی مستقل Fixture و مرز آن
SUPERFICIAL 3 AGILE_CUTOVER_READY MIGRATION HOLD 61 CORRECTED READY_FOR_MEASUREMENT_MIGRATION_REVIEW 0
سه عدد قدیمی و سه نام جدید هیچیک Migration را کامل نمیکنند. Rule منع People scoring تنها Rule پاسشده است. نسخهٔ اصلاحشده صفر Finding ساختاری دارد، اما درستی داده، Fitness سنجهها، کفایت Dual-run، اعتبار Bridge، موفقیت Cutover، بهبود Flow/Quality، Agile maturity یا درستی Decision را ثابت نمیکند. خروجی Review است، نه Cutover Approved.
آزمایشگاه آفلاین ایرانی برای Metric Migration
یک Checkout کاملاً ساختگی و بدون شبکه بسازید: fake Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification. Workflow قدیم `test_started→test_complete` و Candidate جدید `evidence_accepted→decision_ready` است؛ بنابراین Cycle timeها عمداً هممعنا نیستند. Eventهای timeout پیش/پس از fake commit، retry، duplicate، late، reordered، reopen و cancel را وارد کنید.
| آزمون | خرابی Seedشده | انتظار |
|---|---|---|
| Identity | یک Attempt با Work item ادغام شود | HOLD و Scope mismatch |
| Timezone | Tehran display بهجای UTC در Transform | Transform defect |
| Duplicate | Callback دوبار ingest شود | Data-quality finding |
| Late event | Finish پس از Snapshot برسد | Correction/Recompute، نه حذف |
| Semantic | Finish قدیم و جدید متفاوت باشد | Series break، نه Query fix |
| Rollback | Candidate view عدد Unknown دهد | Kill switch و restore آزمایشی |
مرزهای داده و بازار ایران در Lab
Tenant/Order/Attempt/Event/Ledger/Work/Evidence/Run/Build/Snapshot/Metric/Migration/Decision شناسههای جدا و ساختگی دارند. مبلغ فقط IRR خیالی است و تومان با برچسب «نمایشی» نشان داده میشود. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/Bidi، UTC instant، Asia/Tehran view و تاریخ جلالی صرفاً نمایشی آزموده میشوند.
Lab هیچ اتصال شبکه، Production، سازمان/تیم/کاربر/سفارش/پرداخت/PSP/بانک واقعی، پول واقعی، دادهٔ HR، PII، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی ندارد و توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، منابع انسانی یا حریم خصوصی نیست.
Pilot سیروزهٔ مهاجرت سنجهها
- روز ۱ تا ۵: Trigger/Scope/Authority و Current inventory/consumer graph را ببندید.
- روز ۶ تا ۱۰: Disposition، Goal/Question و Future portfolio را Review کنید.
- روز ۱۱ تا ۱۵: Semantic/Data/Event contracts و Frozen validation pack را بسازید.
- روز ۱۶ تا ۲۲: Shadow/Dual-run را بدون Gate، Reward یا Target فعال اجرا کنید.
- روز ۲۳ تا ۲۶: Deltaها را Triage و Comparable/Bridge/Break/Unknown را تعیین کنید.
- روز ۲۷ تا ۲۸: Consumer acknowledgment و Cutover/Rollback rehearsal انجام دهید.
- روز ۲۹ تا ۳۰: Authority فقط CUTOVER، HOLD یا STOP را با Evidence ثبت کند.
ضدالگوهای مهاجرت معیارهای تست
- حذف هر Metric قدیمی فقط چون «Waterfall» است؛
- کپیکردن فهرست Agile KPI از اینترنت؛
- استفاده از Velocity بهعنوان بهرهوری/کیفیت؛
- مقایسهٔ Velocity تیمها یا افراد؛
- نامیدن Burndown بهعنوان Outcome؛
- Cycle time بدون Start/Finish/Item contract؛
- Throughput بهعنوان Value؛
- Defect escape بهعنوان اثربخشی قطعی QA؛
- Defect density بر Story point؛
- Coverage پایین بهعنوان Risk قطعی؛
- Automation ratio بهعنوان بلوغ؛
- NPS بهعنوان معیار نهایی کیفیت؛
- تغییر Query و حفظ همان Label/Target؛
- Backfill کردن Missing با صفر یا Created time؛
- برابرخواستن Old/New با Semantic متفاوت؛
- تبدیل با ضریب جهانی Story point/Velocity/Flow؛
- Restate خاموش تاریخچه و Baseline؛
- Cutover Data بدون View/Alert/API consumer؛
- حذف Pipeline قدیم پیش از Stabilization؛
- دو Truth دائمی بدون Authority؛
- Rollback فقط در حد داشتن Query قدیم؛
- استفادهٔ تنبیهی یا امتیازدهی افراد؛
- Join کردن دادهٔ HR/Chat/Git بدون Purpose/Privacy؛
- اعلام Improvement یا Agile maturity پس از Cutover؛
- اصلاح خاموش عددها و تصمیمهای متاثر.
چکلیست Owner پیش از Cutover
- Trigger/Scope/out-of-scope/Authority/موعد روشن است؟
- Inventory فراتر از Dashboard و شامل Alert/API/Bonus/Gate است؟
- Consumer/Decision/Action هر Metric ثبت شده است؟
- Lineage و downstream dependency کامل یا Unknown است؟
- Keep/Adapt/Replace/Retire/Investigate دلیل و Approver دارد؟
- Future metrics از Goal/Question مشتق شدهاند؟
- Portfolio Outcome/Flow/Quality/Guardrail/Data health متوازن است؟
- Metric/Workflow/Identity/Event contracts نسخهدارند؟
- Start/Finish/Population/Window/Attempt و Null روشناند؟
- Backfill محدودیت و برچسب صادقانه دارد؟
- Frozen validation pack Seedهای دشوار دارد؟
- Dual-run Snapshot/Window/Acceptance/Stop دارد؟
- Delta taxonomy و Owner مشخص است؟
- Comparability/Bridge/Break/Unknown مستند و در View آشکار است؟
- Baseline/Target/Threshold قدیم خاموش کپی نشدهاند؟
- Dashboard/Alert/Export/API و automated decision تست شدهاند؟
- Consumer acknowledgment، Training و Support آماده است؟
- Rehearsal/Rollback/Kill switch و Correction اجرا شدهاند؟
- Stabilization/Retirement/History retention تعریف شده است؟
- `people_scoring=false`، Privacy و Not claimed صریحاند؟
پرسشهای متداول درباره معیارهای تست چابک
بهترین معیارهای تست چابک کداماند؟
فهرست جهانی وجود ندارد. ابتدا Objective، Question، Consumer و Decision را تعریف کنید. سپس Portfolio کوچکی از Outcome، Flow/Predictability، Quality/Risk evidence، Guardrail و Data health بسازید. اگر Kanban را طبق راهنمای آن اجرا میکنید، WIP، Throughput، Work Item Age و Cycle Time حداقل Flow metrics هستند؛ این به معنای KPI بودن همهٔ آنها برای QA نیست.
تفاوت معیارهای تست سنتی و چابک چیست؟
تفاوت سالم از Decision و Operating model میآید، نه از سن Metric. محیط پروژهای ممکن است Completion/Evidence milestone بخواهد؛ Flow پیوسته ممکن است Age/WIP/feedback را لازم داشته باشد. سنجهٔ قدیمیِ Fit را نگه دارید و سنجهٔ جدیدِ بیمصرف را رد کنید. «Traditional» و «Agile» بهتنهایی قرارداد معنایی نیستند.
آیا Velocity KPI خوبی برای تیم QA است؟
معمولاً نه. Velocity میتواند ورودی Forecast داخلی همان تیم باشد، اما Story point بین تیمها هممقیاس نیست و با Split/Estimate/DoD تغییر میکند. آن را Target، Ranking، Bonus، Productivity یا Quality score نکنید و برای افراد بهکار نبرید.
آیا هنگام مهاجرت باید تاریخچهٔ Metric قدیمی را تبدیل کنیم؟
فقط اگر Raw data و Semantic کافی برای Restatement قابلدفاع دارید. در غیر این صورت Original series را حفظ و `SERIES_BREAK` بگذارید. Bridge محدود نیازمند دورهٔ همپوشان، Method، Population، uncertainty و Expiry است؛ ضریب تبدیل جهانی نسازید.
Dual-run معیارهای قدیم و جدید چقدر طول بکشد؟
مدت ثابت جهانی ندارد. Window باید variation، Item mix، cadence تصمیم، رخدادهای کمفراوان و هزینهٔ اجرا را پوشش دهد و Stop/Extension rule داشته باشد. Dual-run تا توضیحپذیری Delta و آمادگی Consumer ادامه دارد، نه تا برابرشدن اجباری دو عدد با Semantic متفاوت.
جمعبندی: سیستم سنجش را مهاجرت دهید، نه اسم Metric را
Agile شدن با حذف Test count و نصب Velocity/Cycle time رخ نمیدهد. Current system، Consumer، Decision، Semantic، Data و History را Inventory کنید؛ هر Metric را Keep/Adapt/Replace/Retire/Investigate کنید؛ Future state را از سؤال بسازید؛ Identity/Workflow/Event را ببندید و با Frozen pack، Shadow و Dual-run اختلافها را بفهمید.
اگر Old/New هممعنا نیستند، Break را پنهان نکنید. Target، View، Alert و Consumer نیز بخشی از Cutover هستند. Rollback را تمرین، History را حفظ و Legacy را کنترلشده Retire کنید. Measurement migration بالغ نه وعدهٔ کیفیت و بهرهوری میدهد و نه افراد را رتبهبندی میکند؛ فقط تصمیم را بر سنجهای Fit، قابلردیابی، محدود و اصلاحپذیر قرار میدهد.
