Definition of Done وقتی مفید است که مرز قابلبررسی Increment را شفاف کند؛ نه وقتی به فهرست «Code review شد، تستها سبزند، QA تأیید کرد» تبدیل شود. دوازده تیک سبز ممکن است به Build قدیمی، Screenshot بیمنبع، Coverage با تعریف نامعلوم یا Approval بدون اختیار متصل باشند. در این حالت Checklist کامل است، اما Evidence لازم برای گفتن Done وجود ندارد.
این راهنما Definition of Done یا DoD را بهصورت Clause Contract + Increment Evaluation طراحی میکند. هر بند باید Scope، Applicability، Obligation، Method، Evidence، Freshness، Failure outcome و Claim limit داشته باشد؛ سپس روی Increment/Build/Commit دقیق ارزیابی شود. نتیجهٔ `DoD met` با Accepted، Released، Successful، Defect-free یا «کیفیت تضمین شد» یکی نیست.
مسیر کوتاه Definition of Done در هشت گام
| گام | پرسش | خروجی |
|---|---|---|
| Authority | حداقل سازمان و DoD محصول چیست؟ | Source hierarchy |
| Baseline | کدام Product/Goal/Build/Increment؟ | Evaluation identity |
| Clause | چه obligation پایداری لازم است؟ | DoD clause |
| Applicability | بند برای این تغییر اعمال میشود؟ | APPLIES/NOT_APPLICABLE |
| Evidence | کدام شاهد جاری و همSubject است؟ | Evidence reference |
| Result | PASS یا FAIL/MISSING/STALE/INVALID؟ | Clause evaluation |
| Aggregate | همهٔ بندهای applicable پاساند؟ | MET/NOT_MET |
| Learning | DoD چگونه آیندهنگر اصلاح شود؟ | Version/Correction |
Definition of Done طبق Scrum Guide چیست؟
در Scrum Guide 2020، Definition of Done توصیف رسمیِ وضعیت Increment در لحظهای است که به سنجههای کیفیت موردنیاز Product رسیده است. DoD تعهدِ Increment است و با ایجاد فهم مشترک از اینکه چه کاری بخشی از Increment است، Transparency میسازد. وقتی یک Product Backlog Item به DoD برسد، Increment شکل میگیرد.
اگر یک PBI به DoD نرسد، نمیتواند بهعنوان Done ارائه یا در Sprint Review بهعنوان Increment نمایش داده شود و برای بررسی آینده به Product Backlog بازمیگردد. این گزاره به معنی پاککردن Work، مخفیکردن یادگیری یا ممنوعیت صحبت دربارهٔ کار ناتمام نیست؛ فقط اجازه نمیدهد ناتمام را Done بنامیم.
DoD چه چیزی نیست؟
| DoD هست | DoD نیست |
|---|---|
| تعهد به Increment | QA entry gate |
| توصیف وضعیت کیفی موردنیاز Product | وعدهٔ کیفیت کامل |
| معیار مشترک Done | فهرست فعالیت بدون Evidence |
| حداقل پایدار و قابلتکرار | تمام Riskهای هر Story |
| مرز عضویت در Increment | Release approval |
| سیاست نسخهدار | چکلیست بیمالک و ابدی |
| قابل ارزیابی روی Subject | حس «بهاندازه کافی خوب است» |
برای تصویر کلی Agile Testing، نقش DoD در جریان Story و اتصال به CI/CD، راهنمای تست چابک را بخوانید. این مقاله بهطور متمایز مالک مهندسی بندهای DoD و ارزیابی Evidence-bound آنهاست.
مالکیت این مقاله: DoD Clause Contract
Organization Minimum / Product Definition of Done
-> Versioned Clause
- intent / source / scope / applicability
- obligation / method / evidence rule / freshness
- failure outcome / owner capability / claim limit
-> Increment / Commit / Build Evaluation
-> APPLIES or NOT_APPLICABLE
-> PASS | FAIL | MISSING | STALE | INVALID | INCONCLUSIVE
-> DoD MET or NOT_MET
-> Backlog / correction / prospective DoD change
Clause Contract جلوی «تیک تفسیری» را میگیرد. اگر بند میگوید «تستها پاس باشند»، باید معلوم باشد کدام Suite، روی کدام Build، با چه Version و چه Outcome vocabulary. اگر میگوید «مستندات بهروز باشند»، باید Artifact، Dependency، Freshness و Evidence تغییر مشخص باشد.
Baseline ارزیابی را قفل کنید
| هویت | نمونهٔ ساختگی | خطر Drift |
|---|---|---|
| Product | SYN-CHECKOUT | DoD محصول دیگر |
| Product Goal | PG-11 | Context ارزش قدیمی |
| Sprint Goal | SG-19 | Scope برنامهٔ متفاوت |
| DoD version | DOD-v6 | بندهای منسوخ |
| Test Basis | BASIS-v6 | Oracle قدیمی |
| Repository/Commit | checkout-api/C19 | Source متفاوت |
| Build/Increment | BUILD-R19/INC-19 | `latest` یا Increment مبهم |
| Risk Registry | RISK-v7 | تعهد نامرتبط |
| Pipeline | PIPE-v5 | Control قدیمی |
| Facts cutoff | ISO instant | Evidence دیررس |
dodEvaluationBaseline: product: SYN-CHECKOUT productGoal: PG-11 sprintGoal: SG-19 dodVersion: DOD-v6 testBasis: BASIS-v6 repository: checkout-api commit: C19 build: BUILD-R19 increment: INC-19 riskRegistry: RISK-v7 pipeline: PIPE-v5 factsCutoff: 2026-08-13T05:10:00Z
ساختار یک بند قابلارزیابی
| فیلد | پرسش | نمونه |
|---|---|---|
| ID/Version | کدام بند؟ | DOD-AUTHZ-1/v2 |
| Intent | چرا وجود دارد؟ | حفظ tenant boundary |
| Source | از کدام authority/risk؟ | RISK-v7#R2 |
| Scope | برای چه Product/Increment؟ | authorization changes |
| Applicability | چه زمانی اعمال میشود؟ | endpoint tenant-scoped changed |
| Obligation | چه چیزی باید برقرار باشد؟ | negative read/write pass |
| Method | چگونه بررسی میشود؟ | AUTHZ-SUITE-v4 |
| Evidence/Freshness | چه شاهدی و چه زمانی؟ | same final Build manifest |
| Failure outcome | اگر برقرار نبود؟ | NOT_DONE |
| Claim limit | چه چیزی ثابت نمیشود؟ | Production overlay ناشناخته |
قالب DoD Clause
dodClause: id: DOD-AUTHZ-1 version: 2 intent: preserve tenant boundary sourceRef: RISK-v7#R2 scope: Product SYN-CHECKOUT / authorization changes applicability: tenant-scoped endpoint or policy changed obligation: cross-tenant read and write negative checks pass method: AUTHZ-SUITE-v4 evidenceRule: immutable manifest bound to commit/build freshness: after final C19 build failureOutcome: NOT_DONE ownerCapability: increment-builders claimLimit: does not prove deployed identity/policy overlay
بند خوب Activity نیست؛ Obligation قابلشاهد است
| عبارت ضعیف | مسئله | بازنویسی بهتر |
|---|---|---|
| Code review شد | Baseline/معیار/Disposition ندارد | Review روی C19 با معیار CR-v3 و Findingهای بستهشده |
| همهٔ تستها پاساند | Population و Result مبهم | Suite obligationهای PIPE-v5 روی BUILD-R19 PASS و هیچ ERROR/MISSING |
| Coverage ۸۵٪ | Metric/Scope/Exclusion مبهم | Branch coverage ابزار/version/scope با Risk obligations جدا |
| مستندات آپدیت شد | Artifact/Freshness نامعلوم | Dependency-mapped docs current for C19 |
| QA تأیید کرد | Authority و Evidence مخلوط | Evidence pack کامل؛ DoD توسط builders ارزیابی شد |
| هیچ Bug مهمی نیست | Registry/Severity/Cutoff مبهم | eligible finding set با policy و disposition مشخص |
هر Risk را وارد DoD نکنید
DoD یک حداقل مشترک و تکرارشونده برای Product است. Risk یا obligation ویژهٔ یک PBI میتواند در Acceptance Criteria، Test Plan، task یا Risk-to-Evidence map بماند. افزودن هر کنترل کمیاب به DoD، clause count و هزینهٔ هر Increment را بالا میبرد و Applicability نمایشی میسازد.
| Candidate | DoD مناسبتر است اگر | جای دیگر مناسبتر است اگر |
|---|---|---|
| Build integrity | برای همهٔ Incrementها لازم است | — |
| Unit/component checks | پایدار و عمومیاند | فقط یک Risk خاص |
| Performance load | هر Increment قابلاجرا و معنادار است | ظرفیت/محیط ویژه میخواهد |
| Accessibility | حداقل component-level عمومی | AT/user study ویژه |
| Security scan | Subject/rules/evidence عمومی | Threat-specific validation |
| Release notes | هر Increment واقعاً نیاز دارد | فقط Release منتخب |
برای طراحی obligationهای Risk-specific و Entry/Exitهای مستقل از DoD، برنامهٔ تست زنده و تصمیممحور مرز مناسبتری ارائه میکند.
Applicability باید قاعده داشته باشد
عبارت «در صورت نیاز» بدون تصمیمگیر، trigger و دلیل، راه فرار است. Applicability را با نوع تغییر، Component، داده، Risk، Interface یا platform تعریف کنید. نتیجه فقط `APPLIES` یا `NOT_APPLICABLE` باشد و N/A دلیل/شاهد داشته باشد. `PASS` را جای Applicability و N/A را جای Failure استفاده نکنید.
Evidence باید به همان Subject وصل باشد
| Evidence | هویت لازم | Claim limit |
|---|---|---|
| Test run | Suite/Build/Data/Env/Run | فقط observed scope |
| Code review | Commit/Diff/criteria/reviewer | نه runtime behavior |
| Static analysis | Commit/tool/rules/config | نه absence of defect |
| Coverage | Build/tool/metric/scope/exclusions | نه oracle/risk adequacy |
| Documentation | Artifact/version/dependency/change | نه reader understanding |
| Deployment check | Artifact/env/config/run | نه Release success |
Dashboard سبز یا Screenshot بدون Manifest ممکن است واقعی باشد، اما Subject و Freshness را ثابت نمیکند. Evidence از Build قبلی برای Build جدید `STALE` یا `FOREIGN` است، مگر Clause reuse rule صریح و معتبر داشته باشد. Hash نیز integrity artifact را کمک میکند، نه صحت نتیجه را.
Vocabulary ارزیابی را ثابت کنید
| Result | معنا | اثر بر DoD |
|---|---|---|
| PASS | Obligation با Evidence معتبر پشتیبانی شد | بند برقرار |
| FAIL | Observation خلاف obligation است | NOT_MET |
| MISSING | Evidence لازم موجود نیست | NOT_MET |
| STALE | Evidence از Subject/نسخه قدیمی است | NOT_MET |
| INVALID | Method/Run/Evidence معتبر نیست | NOT_MET |
| INCONCLUSIVE | نتیجه پاسخ کافی نمیدهد | NOT_MET |
| NOT_APPLICABLE | قاعدهٔ Applicability اعمال نمیشود | با rationale خارج aggregate |
`Skipped`، `Error` یا `Unknown` را PASS نکنید. اگر Clause applicable است، فقط PASS آن را برقرار میکند. نتیجهٔ Aggregate نیز باید هم Clause set و هم Subject/Cutoff را ثبت کند؛ «DoD سبز است» بدون این هویت قابلمصرف نیست.
قالب ارزیابی یک بند
dodEvaluation: id: DOD-EVAL-INC19 clauseRef: DOD-AUTHZ-1/v2 subject: INC-19 / BUILD-R19 / C19 applicability: APPLIES applicabilityReason: tenant authorization changed methodRef: AUTHZ-SUITE-v4 evidenceRef: EV-AUTHZ-R19 evidenceSubject: INC-19 / BUILD-R19 / C19 observedAt: 2026-08-13T05:00:00Z result: PASS limitations: component + synthetic identity unknowns: [production identity overlay] evaluator: increment-builders supersedes: null
الگوریتم Aggregate ساده است، Evidence آن ساده نیست
for each clause in effective DoD version: evaluate applicability if NOT_APPLICABLE: require reason and continue if APPLIES: require result == PASS if every applicable clause == PASS: DOD_MET for exact Increment/Build/Commit/Cutoff else: DOD_NOT_MET DOD_MET != released DOD_MET != accepted DOD_MET != defect-free DOD_MET != successful outcome
DoD با Acceptance Criteria چه تفاوتی دارد؟
| بُعد | Definition of Done | Acceptance Criteria |
|---|---|---|
| دامنه | Increment/Product-level common boundary | PBI/feature-specific behavior/condition |
| هدف | Transparency دربارهٔ عضویت در Increment | شفافسازی انتظار ویژه |
| پایداری | نسبتاً پایدار و نسخهدار | با هر PBI متفاوت |
| Evidence | Clause evaluation | Example/test/review/UAT evidence |
| نقض | PBI بخشی از Increment Done نیست | رفتار خاص پذیرفته نشده |
| همپوشانی | ممکن است هر دو لازم باشند | جای DoD را نمیگیرد |
تقلیل AC به «چه چیزی» و DoD به «چگونه» همیشه دقیق نیست. یک DoD میتواند outcome قابلمشاهده بخواهد و AC میتواند constraint فنی یا policy داشته باشد. تمایز اصلی Scope و purpose است؛ برای Done شدن PBI، هم obligationهای خاص آن و هم DoD جاری باید برقرار باشند.
Definition of Ready جزء Scrum Guide نیست
DoR یک practice اختیاری است، نه Artifact، Commitment یا Rule رسمی Scrum ۲۰۲۰. تیم میتواند برای Readiness سؤال یا policy بسازد، اما نباید آن را به gate سختی تبدیل کند که Refinement و یادگیری را متوقف کند. DoR دربارهٔ امکان شروع/انتخاب است؛ DoD دربارهٔ وضعیت Increment. این دو را در یک Checklist ادغام نکنید.
Done با Accepted فرق دارد
Product Owner accountable برای بیشینهکردن Value و مدیریت Product Backlog است، اما Scrum Guide نمیگوید Product Owner یا QA در پایان DoD را Sign-off کند. Acceptance میتواند business/UAT/policy decision جدا باشد. یک Increment ممکن است DoD را برآورده کند و stakeholder بر اساس Outcome یا نیاز تازه Backlog را Adapt کند.
Done با Released فرق دارد
Increment باید usable باشد و ممکن است پیش از پایان Sprint تحویل شود؛ Sprint Review gate انتشار نیست. بااینحال DoD مت بودن Release decision را خودکار نمیکند. زمانبندی بازار، rollout، عملیات، Risk acceptance یا policyهای دیگر میتوانند تصمیم جدا داشته باشند. برای اتصال Evidence به تصمیم انتشار بدون مخلوطکردن مفاهیم، چارچوب Good Enough Quality و Release Decision را ببینید.
Done با Success یا Value Delivered فرق دارد
DoD وضعیت Increment را شفاف میکند، نه Outcome بازار یا رفتار کاربر را. Feature میتواند Done و Released باشد اما Hypothesis محصول را پشتیبانی نکند؛ یا هنوز دادهٔ Outcome نداشته باشد. Sprint Review برای Inspection نتیجهٔ Sprint و تعیین Adaptation بعدی است، نه مراسم تأیید DoD. راهنمای Sprint Review از Demo تا Outcome Adaptation این جدایی را عملی میکند.
Done با Defect-free یا Quality guarantee فرق دارد
DoD مجموعهٔ محدودی از سنجههای کیفیت موردنیاز Product است. Testها sample و model هستند، ابزارها محدودیت دارند و Unknown باقی میماند. `DOD_MET` میگوید بندهای نسخهٔ مشخص با Evidence موجود روی Subject مشخص برقرارند؛ نبود Defect، امنیت، دسترسپذیری، عملکرد Production، نگهداشتپذیری یا رضایت کاربر را تضمین نمیکند.
QA نگهبان DoD نیست
در Scrum، Developers افرادیاند که هر جنبهٔ Increment قابلاستفاده را میسازند و همیشه accountable هستند کیفیت را با پایبندی به DoD نهادینه کنند. متخصص تست میتواند Risk، Oracle، Testability، Method، Evidence rule و Claim limit را غنی کند؛ ولی DoD «قرارداد ورود کار به QA» یا حق وتوی شخصی QA نیست.
شرح accountabilities و مشارکت تخصص تست در رویدادها در راهنمای نقش QA در Scrum آمده است. مدل دقیقتر Contribution و Decision right نیز در رهبری تضمین کیفیت با مالکیت همگانی از QA gate جلوگیری میکند.
حداقل سازمان و DoD محصول را لایهبندی کنید
| لایه | کارکرد | قانون |
|---|---|---|
| Organization minimum | استاندارد لازم برای همه | تیم کمتر از آن نمیرود |
| Product DoD | مرز مشترک Increment محصول | حداقل سازمان + نیاز Product |
| Component applicability | قاعدهٔ اعمال بند | نه DoD مستقل پنهان |
| PBI obligations | ریسک/رفتار ویژه | AC/Plan/Task |
| Release policy | تصمیم انتشار | جدا از Done |
اگر سازمان استاندارد DoD دارد، همهٔ Scrum Teamها باید دستکم آن را رعایت کنند. اگر ندارد، Developers باید DoD مناسب Product را بسازند. این «هر تیم DoD منحصربهفرد خود» نیست؛ اگر چند Scrum Team روی یک Product کار میکنند، باید یک DoD مشترک را تعریف و رعایت کنند.
DoD قویتر همیشه DoD طولانیتر نیست
Clause بیشتر میتواند coverage مفید بسازد یا صرفاً صف، N/A، Screenshot و تیک صوری زیاد کند. DoD باید ambitious اما قابلتکرار در هر Increment باشد. اگر تیم توان اجرای پایدار یک obligation را ندارد، Gap را پنهان نکنید: capability work را Plan کنید، Scope Product را روشن کنید و از ادعای Done غلط خودداری کنید.
| سلامت DoD | Metric | Countermetric |
|---|---|---|
| Clarity | ambiguous clause findings | wording burden |
| Evidenceability | valid evidence / applicable | evidence-production cost |
| Freshness | same-subject current evidence | unnecessary reruns |
| Stability | change frequency/reason | stale policy |
| Applicability | justified N/A rate | gaming/overbroad clause |
| Flow | NOT_DONE reason age | premature PASS |
| Learning | late signal→clause review | clause explosion |
Coverage threshold را از Quality proof جدا کنید
«حداقل ۸۵٪ Unit Test Coverage» بدون metric نوع line/branch/function، ابزار/version، Source scope، generated code، exclusions، denominator و تغییرپذیری بیمعناست. حتی با تعریف کامل، Coverage فقط اجرای عناصر طبق مدل ابزار را نشان میدهد؛ Oracle strength، Risk coverage یا رفتار درست را ثابت نمیکند.
| اگر Coverage در DoD است | باید روشن باشد |
|---|---|
| Subject | Commit/Build/modules |
| Metric | line/branch/function/mutation |
| Tool | name/version/config |
| Population | included/excluded/generated |
| Rule | absolute/delta/changed-code |
| Evidence | machine-readable manifest |
| Limit | not defect/risk adequacy |
«هیچ Critical/Major بازی نیست» نیاز به قرارداد دارد
Severity نام ثابت جهانی نیست. Clause باید Registry، Product/Build scope، canonical defect identity، severity policy/version، eligible states، duplicate handling، facts cutoff و outcome را مشخص کند. Finding پذیرفتهشده با Exception ممکن است برای Release قابلتصمیم باشد، اما اگر DoD آن را ممنوع میکند، Exception کار را Done نمیکند.
Non-functional را با حداقل پایدار و Risk-specific جدا کنید
| ویژگی | DoD minimum نمونه | Risk-specific evidence |
|---|---|---|
| Security | dependency/secret/static controls bound to Build | threat/authorization/dynamic/runtime |
| Performance | component budget for changed path | system load/capacity/production SLI |
| Accessibility | semantic/component checks | manual AT/representative user |
| Reliability | error/retry/recovery contract checks | soak/chaos/incident evidence |
| Observability | identity/correlation fields | deployed detection/on-call response |
| Privacy | data classification/log redaction | context-specific review/assessment |
کار DoD را در Sprint Planning مرئی کنید
DoD work رایگان نیست. Fixture، Review، documentation، observability، evidence packaging و non-functional control روی ظرفیت و dependency اثر دارند. هنگام Forecast باید Work لازم برای Increment Done دیده شود؛ ولی DoD را به estimation formula یا امتیاز مخفی QA تبدیل نکنید. Sprint Planning مبتنی بر Goal/Risk/Evidence این اتصال را پوشش میدهد.
Partial Done وجود ندارد
برای یک DoD و Subject معین، نتیجه یا MET است یا NOT_MET. درصد تیک، ۹۰% Done، «فقط مستندات مانده» یا Demo خوب، عضویت در Increment را ایجاد نمیکند. Work انجامشده را نگه دارید و شفاف کنید؛ PBI ناتمام به Backlog برمیگردد. Scope آن میتواند بعداً دوباره بررسی یا شکسته شود، اما تاریخچه را بازنویسی نکنید.
Story Point و Velocity قانون Done را تغییر نمیدهند
Story Point و Velocity در Scrum Guide تعریف نشدهاند. اینکه تیم برای Reporting داخلی چه چیزی را میشمارد، policy محلی است؛ عدد نباید کار NOT_MET را Done کند. وعدهٔ قطعی «هیچ امتیازی محاسبه نمیشود» نیز از Scrum Guide نمیآید. بهجای بازی با امتیاز، Increment state و Work باقیمانده را شفاف نگه دارید.
Waiver و Exception کار را Done نمیکنند
اگر Clause جاری میگوید obligation باید برقرار باشد و نیست، Outcome `NOT_MET` است. Risk owner میتواند دربارهٔ اقدام یا Release بیرون از این ادعا تصمیم بگیرد، اما نمیتواند Evidence را PASS یا DoD را متشده اعلام کند. اگر Clause واقعاً نامناسب شده، فرآیند Change Control جدا و آیندهنگر لازم است؛ حذف اضطراری برای سبزکردن Increment، Transparency را میشکند.
DoD را چگونه تغییر دهیم؟
| مرحله | سؤال | خروجی |
|---|---|---|
| Signal | چه Failure/هزینه/Gap دیده شد؟ | Observation |
| Proposal | کدام Clause چرا تغییر کند؟ | Diff/intent/source |
| Impact | ابزار/مهارت/ظرفیت/تیمها؟ | impact assessment |
| Trial | روی نمونه قابلاجراست؟ | evidence/guardrail |
| Authority | org minimum/product alignment؟ | approved version |
| Effective | از کدام تاریخ/Increment؟ | effectiveFrom |
| Migration | کار قبلی چه میشود؟ | backlog/known gap |
| Review | Keep/Adapt/Remove؟ | versioned learning |
Retrospective مکان طبیعی برای بررسی effectiveness و پیشنهاد Experiment است، اما تنها زمان یا authority تغییر DoD نیست. تغییر میتواند از Incident، Product Risk، استاندارد سازمان یا یادگیری فنی آغاز شود. برای تبدیل نظر به Hypothesis/Experiment/Guardrail، راهنمای Sprint Retrospective را به کار ببرید.
DoD یک سند زنده است، نه سند ناپایدار
Version، Authority، effectiveFrom، supersedes، dependency و change reason را نگه دارید. Pipeline، template، dashboard و team handbook باید به نسخهٔ جاری اشاره کنند. تغییر Source بدون propagation، Drift میسازد. الگوی Authority Map، Freshness و Correction در مستندات تست زنده قابل استفاده است.
Automation باید Evidence تولید کند، نه تیک تزئینی
- DoD version و Clause ID را در Manifest نگه دارید.
- Commit/Build/Artifact را immutable یا دقیق pin کنید.
- PASS/FAIL/ERROR/SKIP/INCONCLUSIVE را جدا کنید.
- Tool/rules/config/data/environment version را ثبت کنید.
- Evidence link، digest، observedAt و retention بدهید.
- Pipeline نباید خودش Release یا Quality را تأیید کند.
Manual Evidence هم معتبر است اگر Subject، Method، Observer، Observation، Limitation و Artifact داشته باشد. «خودکار» مترادف objective یا درست نیست؛ «دستی» نیز مترادف غیرقابلتکرار نیست.
AI در DoD: پیشنهاد بند، نه اعلام Done
AI میتواند Clause candidate، ambiguity، missing field، applicability question یا change impact پیشنهاد دهد. Source/version، prompt/template، model/version، input classification، output digest و reviewer را ثبت کنید. مدل نباید Requirement یا Evidence بسازد، Screenshot را بیزمینه PASS کند، PII/Secret بگیرد، Exception را تصویب یا Done/Release/Quality را اعلام کند.
آزمایش تکرارپذیر: آیا ۱۲ تیک یعنی Done؟
یک Fixture کاملاً ساختگی و بدون dependency با Node.js ۲۶.۷.۰ اجرا شد. Gate سطحی دید `checkedItems=۱۲` و `checklistItems=۱۲` و نتیجهٔ DONE داد. Validator سپس Baseline، Clause contract، Evaluation subject، Evidence، governance و improvement را بررسی کرد.
خروجی Validator: ۶۳ Finding
fixture: SYN-DEFINITION-OF-DONE-EVIDENCE-01 runtime: Node.js v26.7.0 superficial: DONE | checkedItems=12/12 auditedDraft: NOT_DONE findings (63): 1 stale-product:SYN-CART->SYN-CHECKOUT 2 stale-productGoal:PG-9->PG-11 3 stale-sprintGoal:SG-18->SG-19 4 stale-dodVersion:DOD-v3->DOD-v6 5 stale-basis:BASIS-v4->BASIS-v6 6 stale-repository:checkout-web->checkout-api 7 stale-commit:C17->C19 8 stale-build:latest->BUILD-R19 9 stale-increment:INC-18->INC-19 10 stale-riskRegistry:RISK-v4->RISK-v7 11 stale-pipeline:PIPE-v3->PIPE-v5 12 DOD-1-intent-missing 13 DOD-1-source-missing 14 DOD-1-scope-missing 15 DOD-1-applicability-missing 16 DOD-1-obligation-not-verifiable 17 DOD-1-method-unbound 18 DOD-1-evidence-rule-insufficient 19 DOD-1-freshness-missing 20 DOD-1-failure-not-NOT_DONE 21 DOD-1-qa-gatekeeper-owner 22 DOD-1-claim-limit-missing 23 duplicate-clause:DOD-1 24 DOD-1-source-missing 25 DOD-1-method-unbound 26 DOD-1-evidence-rule-insufficient 27 DOD-1-freshness-missing 28 DOD-1-failure-not-NOT_DONE 29 DOD-1-qa-gatekeeper-owner 30 DOD-1-claim-limit-missing 31 DOD-1-wrong-subject 32 DOD-1-applicability-invalid 33 DOD-1-foreign-evidence 34 DOD-1-observation-time-missing 35 DOD-1-evaluator-missing 36 DOD-1-unknowns-missing 37 unknown-clause:DOD-99 38 DOD-99-applicability-invalid 39 DOD-99-evidence-missing 40 DOD-99-foreign-evidence 41 DOD-99-observation-time-missing 42 organizational-minimum-reference-missing 43 product-dod-missing 44 multiple-teams-dod-not-aligned 45 qa-gatekeeper 46 product-owner-accepts-done 47 approval-as-quality-proof 48 acceptance-criteria-conflated-with-dod 49 definition-of-ready-misrepresented-as-scrum 50 done-conflated-with-released 51 done-conflated-with-success 52 done-conflated-with-no-defects 53 not-done-presented-as-done 54 partial-done-credit 55 points-used-to-override-dod 56 exception-used-to-mark-done 57 prospective-change-control-missing 58 correction-path-missing 59 quality-debt-speed-guarantee 60 improvement-baseline-missing 61 improvement-measure-missing 62 improvement-guardrail-missing 63 team-ranking-metric corrected: READY_FOR_DOD_EVALUATION | findings=0
نسخهٔ اصلاحی چه کرد؟
نسخهٔ اصلاحی Product/Goals/DOD-v6/BASIS-v6/Repository/C19/BUILD-R19/INC-۱۹/RISK-v7/PIPE-v5 را pin کرد؛ دو Clause یکتا برای tenant authorization و traceability ساخت؛ Intent/Source/Scope/Applicability/Obligation/Method/Evidence/Freshness/NOT_DONE/Owner/Claim limit افزود؛ Evidenceها را به همان Increment/Build/Commit بست؛ Unknownها را نگه داشت؛ حداقل سازمان و DoD مشترک Product را ثبت کرد؛ QA/PO gate، Partial Done، waiver و اختلاط AC/DoR/Release/Success را حذف کرد؛ و Change Control و Correction ساخت.
خروجی `READY_FOR_DOD_EVALUATION` عمداً DONE نیست. Validator فقط میگوید ساختار برای ارزیابی آماده است؛ صحت Source/Method/Evidence، adequacy بندها، usability Increment، نبود Defect، Product quality، کاهش Debt، سرعت Delivery، Success، Acceptance یا Release را ثابت نمیکند.
آزمایشگاه فارسی و آفلاین DoD
Lab یک Checkout خیالی و بدون شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation. DoD فقط روی Increment ساختگی INC-۱۹ و Build ساختگی BUILD-R19 ارزیابی میشود. هیچ تیم، شرکت، کاربر، تراکنش یا Product واقعی در کار نیست.
| Clause candidate | Evidence | Unknown/Countercheck |
|---|---|---|
| duplicate callback idempotency | state/property run | real dependency ordering |
| tenant boundary | negative component/system | production overlay |
| money representation | canonical IRR property | display integration |
| trace correlation | Attempt/Event/Build manifest | production sampling |
| reconciliation | Ledger/Order invariant | operational recovery |
- IRR کاملاً خیالی Canonical است؛ تومان فقط View صریح.
- رقم فارسی/عربی/لاتین، Unicode و RTL/LTR در Fixture کنترل میشوند.
- زمان UTC instant و Asia/Tehran view است؛ جلالی فقط Presentation است.
- Tenant/Order/Attempt/Event/Ledger/Run/Build/Increment/Evidence identity جداست.
- نام/موبایل/ایمیل/IP/PAN/CVV2/OTP/cookie/token/credential/log واقعی وجود ندارد.
- هیچ ادعای بانکی، مالی، حقوقی، مالیاتی، امنیتی یا حریم خصوصی ایران ساخته نمیشود.
۲۹ ضدالگوی Definition of Done
- DoD بهعنوان تضمین کیفیت/موفقیت
- QA entry gate
- QA نگهبان کیفیت
- Product Owner accepts Done
- Approval برابر Quality proof
- Checklist بدون Clause contract
- تیک بدون Evidence
- Dashboard سبز بدون Subject
- Build=`latest`
- Evidence از Build قدیمی
- همهٔ تستها پاساند
- Coverage ۸۵٪ بیتعریف
- هیچ Major/Critical بیRegistry
- Documentation updated بیArtifact
- In case needed بیApplicability
- N/A برای Failure
- Skipped/Error برابر PASS
- هر Risk داخل DoD
- هر تیم DoD مستقل برای یک Product
- DoD همان Acceptance Criteria
- DoR بهعنوان Rule رسمی Scrum
- Done برابر Released
- Done برابر Successful
- Done برابر Defect-free
- Partial Done یا ۹۰% Done
- Story Point جای DoD
- Exception کار را Done میکند
- تغییر retroactive برای سبزشدن
- وعدهٔ Debt/Speed/Quality improvement
Pilot سیروزهٔ DoD Evidence
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | Authority/Product/current DoD audit | Baseline |
| روز ۴–۷ | Clause ambiguity/source/scope | candidate clauses |
| روز ۸–۱۰ | Applicability/Method/Evidence | contract vNext |
| روز ۱۱–۱۵ | سه Increment تاریخی | dry-run findings |
| روز ۱۶–۲۰ | Pipeline/manual manifests | traceable evaluation |
| روز ۲۱–۲۵ | flow/cost/guardrails | impact review |
| روز ۲۶–۳۰ | align/effectiveFrom/adopt | versioned DoD |
Pilot موفق یعنی چند Clause مبهم قابلارزیابی شده و Evidence به Subject وصل است؛ نه اینکه Defect، Debt یا Cycle time حتماً کاهش یافته باشد. اگر Clause count و evidence production صف میسازد، Scope و Value هر بند را Adapt کنید.
چکلیست Audit Definition of Done
- Organization minimum و Product DoD جاریاند.
- چند تیم روی یک Product یک DoD مشترک دارند.
- DoD version/effectiveFrom/supersedes مشخص است.
- Product/Goal/Basis/Repo/Commit/Build/Increment/Risk/Pipeline/Cutoff pin شدهاند.
- Clause ID یکتا، Intent و Source معتبر دارد.
- Scope و Applicability قابلتصمیماند.
- Obligation قابلمشاهده و Method نسخهدار است.
- Evidence rule، Subject و Freshness روشناند.
- Failure outcome برای بند applicable برابر NOT_DONE است.
- Claim limit و Unknown باقی میماند.
- PASS/FAIL/MISSING/STALE/INVALID/INCONCLUSIVE جدا هستند.
- N/A دلیل دارد و جای Failure استفاده نشده است.
- Evidence خارجی، stale یا screenshot-only رد میشود.
- QA/PO/Approval به gate Done تبدیل نشدهاند.
- DoD از AC، DoR، UAT، Release و Outcome جداست.
- Partial credit، Story Point یا Exception وضعیت را عوض نمیکند.
- DoD work در Plan و ظرفیت دیده شده است.
- Change آیندهنگر، impact-tested و versioned است.
- Correction تاریخچه را حفظ میکند.
- Automation/AI authority یا Evidence جعلی نمیسازند.
- Metric برای سیستم است، نه رتبهبندی تیم.
- نتیجه Quality/Debt/Speed/Success guarantee نمیسازد.
پرسشهای متداول
Definition of Done به زبان ساده چیست؟
توصیف رسمی وضعیت Increment وقتی است که به سنجههای کیفیت موردنیاز Product رسیده باشد. DoD فهم مشترک میسازد که چه کاری واقعاً بخشی از Increment است. برای استفاده قابلاعتماد، بندها را نسخهدار و با Scope، Evidence و Failure outcome تعریف کنید.
تفاوت DoD و Acceptance Criteria چیست؟
DoD مرز مشترک Product/Increment و نسبتاً پایدار است؛ Acceptance Criteria معمولاً انتظار یا شرط ویژهٔ یک PBI را روشن میکند. هر دو ممکن است برای Done شدن لازم باشند. تفاوت را فقط به «چگونه» در برابر «چه چیزی» تقلیل ندهید؛ Scope و purpose مهمترند.
چه کسی مسئول Definition of Done است؟
اگر سازمان استاندارد دارد، حداقل لازم است؛ در غیر این صورت Developers DoD مناسب Product را ایجاد میکنند و باید به آن پایبند باشند. چند Scrum Team روی یک Product باید DoD مشترک داشته باشند. متخصص تست مشارکت میکند، اما QA gatekeeper یا تأییدکنندهٔ انحصاری نیست.
اگر یک PBI در پایان Sprint به DoD نرسد چه میشود؟
بخشی از Increment Done نیست و برای بررسی آینده به Product Backlog بازمیگردد. Work و یادگیری را مخفی نکنید، اما آن را Done نمایش ندهید. Scrum دربارهٔ Story Point/Velocity قانون قطعی نمیدهد؛ policy شمارش محلی نباید وضعیت Increment را بازنویسی کند.
آیا میتوان برای یک مورد فوری از DoD استثنا گرفت؟
Exception میتواند برای Risk/Release تصمیم جدا بسازد، اما Clause نقضشده را PASS و Work را Done نمیکند. اگر بند نامناسب است، DoD را با Source، impact، effectiveFrom و هماهنگی Product برای آینده تغییر دهید؛ تغییر retroactive برای سبزکردن Increment Transparency را از بین میبرد.
جمعبندی: Done یک ادعای Evidence-bound است
Definition of Done را از Checklist فعالیت به قرارداد بندها تبدیل کنید: Authority و Product را روشن کنید، Baseline دقیق را pin کنید، هر Clause را با Intent/Source/Scope/Applicability/Obligation/Method/Evidence/Freshness/NOT_DONE/Claim limit بسازید، فقط Evidence همSubject را بپذیرید و Aggregate را بدون Partial credit یا waiver محاسبه کنید. سپس Done را از Acceptance، Release، Success و Defect-free جدا نگه دارید. این ساختار Transparency را قابلممیزی میکند؛ کیفیت یا موفقیت را تضمین نمیکند.
