جلسهٔ Sprint Retrospective میتواند تختهای پر از یادداشت، رأی و Action Item تولید کند و با این حال هیچ یادگیری قابلبررسی نسازد. تعداد برگهها، مشارکت ظاهری یا قول «اسپرینت بعد بهتر میشویم» نشان نمیدهد تیم چه چیزی را مشاهده کرده، کدام تفسیر هنوز Hypothesis است، چه تغییر کوچکی را آزمایش میکند، پیامد جانبی را چگونه میسنجد و در چه تاریخی دربارهٔ Adopt، Adapt یا Stop تصمیم میگیرد.
این راهنما رترواسپکتیو را به «جلسهٔ QA» یا کارخانهٔ اقدام تبدیل نمیکند. یک Contract عملی میسازد که در آن Scrum Team، Sprint گذشته را با Baseline درست بازرسی میکند، Observation را از Cause جدا نگه میدارد، یک Hypothesis ابطالپذیر میسازد و Improvement را مانند Experiment محدود و برگشتپذیر دنبال میکند. نتیجه، وعدهٔ کیفیت نیست؛ یک حلقهٔ یادگیری با Evidence، Guardrail، Review date و Decision روشن است.
مسیر کوتاه: Retro قابلآزمون در هفت گام
| گام | پرسش | خروجی حداقلی |
|---|---|---|
| Baseline | دقیقاً کدام Sprint و سیاستها را بازرسی میکنیم؟ | Sprint/Goal/Backlog/DoD/Workflow/Cutoff |
| Observe | چه اتفاقی، کجا و چه زمانی دیده شد؟ | Observation با Source |
| Interpret | چه توضیحهای رقیبی داریم؟ | Hypothesis + Falsifier |
| Choose | کدام اهرم در اختیار تیم است؟ | Option/Constraint/Authority |
| Experiment | چه تغییر کوچک و برگشتپذیری را امتحان میکنیم؟ | Prediction + Owner + Window |
| Measure | چه Signal و Guardrailی را با چه تعریف میسنجیم؟ | Baseline/Measure/Guardrail |
| Review | چه زمانی Adopt، Adapt یا Stop میکنیم؟ | Evidence + Decision + Follow-up |
اگر وقت کم است، یک Observation معتبر، یک Hypothesis صریح و یک Experiment قابلبازگشت از دهها شکایت و سه اقدام مبهم ارزشمندتر است. محدودکردن Work in Progress به خودِ بهبودها نیز ضروری است؛ تیمی که هر Sprint پنج تغییر همزمان میدهد، بعداً نمیداند کدام تغییر چه اثری داشته است.
خط مبنای رسمی Scrum: Retrospective دقیقاً برای چیست؟
در راهنمای رسمی Scrum، هدف Sprint Retrospective برنامهریزی راههایی برای افزایش کیفیت و اثربخشی است. Scrum Team بررسی میکند Sprint گذشته از نظر افراد، تعاملها، فرایندها، ابزارها و Definition of Done چگونه پیش رفت؛ فرضهایی را که تیم را گمراه کردهاند بررسی میکند؛ تغییرهای سودمند را شناسایی میکند و اثرگذارترین بهبودها را در اولین فرصت پی میگیرد. این بهبودها حتی میتوانند به Sprint Backlog بعدی افزوده شوند.
- Retrospective آخرین رویداد Sprint است و برای Sprint یکماهه حداکثر سه ساعت Timebox دارد؛ برای Sprint کوتاهتر معمولاً کوتاهتر است.
- اعضای Scrum Team عبارتاند از Product Owner، Scrum Master و Developers؛ Scrum درون تیم نقش فرعی Tester یا QA تعریف نمیکند.
- سه سؤال «چه خوب بود/چه بد بود/چه کنیم» قانون Scrum نیست؛ Start–Stop–Continue، Sailboat و Mad–Sad–Glad نیز Technique اختیاریاند.
- Scrum تعداد Action Item، رأیگیری، حضور مدیر، ابزار تخته یا هدف پوشش تست تعیین نمیکند.
- راهنما وعده نمیدهد که برگزاری Retro خودبهخود کیفیت محصول، رضایت مشتری یا عملکرد تیم را بالا میبرد.
Retrospective چیست و چه چیزی نیست؟
| Artifact/رویداد | موضوع بازرسی | خروجی | Retro نیست چون… |
|---|---|---|---|
| Sprint Review | Outcome و Increment در محیط تغییرکرده | Feedback و Product Backlog adaptation | روی محصول و آیندهٔ آن متمرکز است |
| Daily Scrum | پیشرفت به Sprint Goal | Plan روز بعد/Sprint Backlog adaptation | حلقهٔ روزانهٔ جریان کار است |
| Defect Triage | Finding/Defect مشخص | Disposition/Priority/Owner | صف نقص را اداره میکند |
| RCA/Postmortem | رخداد یا Failure مهم | مدل علّی و اقدام سیستمی | تحقیق عمیق مستقل میخواهد |
| Performance review | کار فرد | ارزیابی شغلی | ریسک بینفردی و اختیار متفاوت دارد |
| Sprint Retrospective | نحوهٔ کار Scrum Team در Sprint | بهبود/Experiment قابلپیگیری | نه دادگاه، نه گزارش QA و نه Release gate |
مرور محصول و Retro مکملاند اما «What در برابر How» تنها یک میانبر آموزشی است. Retro میتواند دربارهٔ DoD و شیوهٔ ساخت Increment بحث کند و Review میتواند تغییر محیط و روش استفاده را آشکار کند. مرز عملی این است: Sprint Review Outcome و جهت محصول را با ذینفعان بازرسی میکند؛ Retro نحوهٔ کار خود Scrum Team را برای افزایش کیفیت و اثربخشی بازرسی میکند.
مالکیت محتوایی این راهنما: Retrospective Experiment Contract
Current Sprint Baseline -> Observation Registry -> Pattern / Tension / Bright Spot -> Competing Hypotheses -> Bounded Improvement Option -> Experiment + Prediction -> Measure + Guardrail + Stop Rule -> Review Evidence -> Adopt | Adapt | Stop | Escalate -> Learning Record / Next Sprint Backlog
این حلقه عمداً «Problem→Solution→Owner» نیست. ابتدا واقعیت از تفسیر جدا میشود؛ سپس توضیحها بهعنوان فرضیه رقابت میکنند؛ در پایان یک تغییر کوچک برای تولید Evidence انتخاب میشود. Owner مسئول هماهنگی Experiment است، نه مقصرِ مسئله و نه تنها فرد مسئول کیفیت.
Contract خط مبنا: Retro کدام Sprint را میبیند؟
| فیلد | نمونه | چرا لازم است؟ |
|---|---|---|
| Retro/Sprint ID | RETRO-17 / S17 | جلوگیری از ترکیب Sprintها |
| Sprint Goal | SG-17 | فهم Context تصمیمها |
| Sprint Backlog snapshot | SB-D4 | Scope و Plan واقعی |
| DoD/Workflow | DOD-v4 / FLOW-v2 | معنای Done و Signal |
| Increment/Build/Environment | INC-B17 / B17 / ENV7 | اتصال Observation فنی |
| Facts cutoff | 2026-08-12T13:30:00Z | مرز تازگی داده |
| Participant scope | SCRUM-TEAM-ST17 | شفافیت دیدگاههای حاضر/غایب |
| Prior experiment | E0/decision pending | بستن حلقهٔ قبلی |
retroBaseline: retroId: RETRO-17 sprintId: S17 sprintGoal: SG-17 sprintBacklogSnapshot: SB-D4 definitionOfDone: DOD-v4 workflowPolicy: FLOW-v2 increment: INC-B17-DONE build: B17 environment: ENV7 factsCutoff: 2026-08-12T13:30:00Z participantScope: SCRUM-TEAM-ST17
Observation، Interpretation و Judgment را مخلوط نکنید
| عبارت | نوع | بازنویسی امنتر |
|---|---|---|
| «تستر دیر شروع کرد.» | نسبتدهی فردی/تفسیر | ۳ از ۸ آیتم بیش از ۴ ساعت در ready-for-verify ماندند. |
| «محیط تست همیشه خراب است.» | تعمیم | ENV7 در Runهای R4 و R7 پاسخ health-check نامعتبر داد. |
| «علت باگ، Unit Test کم بود.» | ادعای علّی | Failure F12 رخ داد؛ رابطهٔ آن با Test portfolio هنوز Hypothesis است. |
| «Pairing جواب داد.» | نتیجه بدون Baseline | در Window آزمایشی، Age طبق تعریف v2 تغییر کرد؛ Alternative explanationها باقیاند. |
| «تیم مسئولیتپذیر نیست.» | برچسب هویتی | برای ۲ Action قبلی Owner/Review date ثبت نشده بود. |
Observation باید تا حد امکان Subject، Source، زمان، Context و limitation داشته باشد. این سختگیری به معنی حذف تجربهٔ انسانی نیست. یک تجربه یا احساس نیز داده است، اما نوع Source آن باید «self-report» یا «participant observation» باشد؛ نه اینکه بدون بررسی به واقعیت عمومی یا علت قطعی تبدیل شود.
Observation Registry: قالبی برای واقعیت، تجربه و محدودیت
observation: id: O1 type: workflow-signal | event | self-report | bright-spot subject: ready-for-verify items in S17 source: FLOW-S17 | participant-p3 observedAt: 2026-08-12T09:10:00Z context: FLOW-v2, 8 eligible items statement: 3 items aged more than 4 team-hours limitation: small window; shared-stage outage overlaps interpretation: none privacyClass: team-aggregate
- Observationهای تکراری را با `duplicateOf` وصل کنید؛ تعداد رأی یا تکرار، صحت Cause را اثبات نمیکند.
- Bright Spot را نیز ثبت کنید: رفتاری که در Context مشخص نتیجهٔ مطلوب داشت، نه فقط مشکل.
- Unknown و Missing Perspective را آشکار کنید؛ سکوت افراد به معنی موافقت نیست.
- دادهٔ فردی را فقط وقتی ضروری، مجاز و کمینه است وارد کنید؛ Signal تیمی را به رتبهبندی افراد تبدیل نکنید.
Timeline برای ترتیب رویداد است، نه اثبات علت
یک Timeline سبک میتواند تغییر Requirement، آمادهشدن Data، Failure محیط، Handoff و Evidence را کنار هم بگذارد. تقدم زمانی شرط لازم برخی روابط علّی است، اما کافی نیست. اگر قطعی محیط قبل از تأخیر رخ داده، هنوز باید توضیحهای دیگری مانند Scope change، WIP، Dependency یا تعریف مبهم Finish بررسی شوند.
| Instant | Event | Source | Known | Unknown |
|---|---|---|---|---|
| 08:00Z | P2 ready-for-verify | FLOW-S17 | State transition | دلیل صف |
| 08:20Z | Stage access denied | ENV-E12 | Access failure | دامنهٔ اثر |
| 12:30Z | First accepted Evidence | EV-P2-B17 | Age=۴.5h طبق v2 | Counterfactual بدون outage |
Signal بدون Definition فقط عدد است
عبارتهایی مانند «زمان تست زیاد شد»، «باگ بالا رفت» یا «پوشش کم است» Population، Unit، Window و Policy ندارند. برای هر Signal بنویسید چه چیزی وارد مخرج میشود، Start/Finish چیست، داده از کدام Snapshot آمده، Missing و Outlier چگونه رفتار میکنند و آیا تعریف در طول Experiment ثابت مانده است.
signalDefinition: id: SIG-READY-AGE-v2 name: ready-to-verify age population: items entering ready-for-verify in S17 start: FLOW-v2 transition timestamp finish: first accepted evidence for same item/build unit: team-hour statistic: median + raw distribution exclusions: cancelled items, declared data errors missing: reported, never silently dropped purpose: inspect flow; not individual performance
امنیت روانی: شرط مفید یادگیری، نه شعار یا تضمین
پژوهش کلاسیک Amy Edmondson، امنیت روانی تیم را باور مشترک به امنبودن ریسکپذیری بینفردی تعریف و در مطالعهای چندروشی روی ۵۱ تیم تولیدی، ارتباط آن را با رفتار یادگیری گزارش کرد. این مطالعهٔ اولیهٔ Psychological Safety and Learning Behavior پشتوانهای برای توجه به Speak-up و بحث خطاست؛ اما اثبات نمیکند یک تمرین، Prime Directive، تختهٔ ناشناس یا حذف مدیر در هر سازمانی امنیت میسازد یا کیفیت نرمافزار را تضمین میکند.
| نشانهٔ عملی | کنترل | چیزی که اثبات نمیکند |
|---|---|---|
| امکان مخالفت با Cause غالب | Round مستقل و Hypothesis رقیب | نبود ترس پنهان |
| امکان Pass کردن | اجبارنکردن به افشای تجربه | رضایت یا موافقت |
| جداسازی داده از ارزیابی فرد | Aggregate/role-safe views | نبود سوءاستفادهٔ آینده |
| پذیرش اصلاح Facilitator | Correction log | بیطرفی کامل |
| مسیر خارج از Retro | Confidential escalation | حلشدن تعارض قدرت |
Prime Directive و Blameless چه محدودیتی دارند؟
یک افتتاحیهٔ همدلانه میتواند Tone جلسه را بهتر کند، ولی جای Accountability، تحقیق یا محافظت سازمانی را نمیگیرد. Blameless یعنی تمرکز بر شرایط و رفتارهای قابلتغییر، نه حذف مسئولیت تصمیم یا نادیدهگرفتن تخلف. اگر موضوع آزار، تلافی، امنیت، حریم خصوصی، تقلب یا تعارض حقوقی است، Retro عمومی محل حل کامل آن نیست؛ مسیر مجاز و محرمانهٔ سازمان لازم است.
از Hypothesis رقیب استفاده کنید، نه Root Cause فوری
| Observation | Hypothesis A | Hypothesis B | چه چیزی تفکیک میکند؟ |
|---|---|---|---|
| Age تأیید بالا رفت | Batch بزرگ بود | Stage access مانع شد | Size-stratified age + access events |
| Reopen بیشتر شد | Oracle مبهم بود | Build identity گم شد | Finding sample + lineage audit |
| Regression طولانی شد | Suite کند است | Failure triage صف ساخته | runtime distribution + triage wait |
| Feedback کم بود | Task نامرتبط بود | ریسک صحبتکردن بالا بود | anonymous pulse + interview، با محدودیت |
hypothesis: id: H1 observationRefs: [O1, O2] statement: a daily bounded pair window may reduce queue age mechanism: oldest eligible item receives missing capability earlier competing: stage access is dominant constraint confidence: PLAUSIBLE falsifier: no age change in two windows or guardrail worsens unknowns: small n, outage overlap, item mix
Action Item را به Improvement Experiment تبدیل کنید
| Action مبهم | Experiment قابلآزمون |
|---|---|
| «تست را زودتر شروع کنیم.» | برای قدیمیترین آیتم eligible، روزانه یک Pair window سیدقیقهای طی S18؛ Prediction، Measure و Guardrail مشخص. |
| «پوشش را ۷۵٪ کنیم.» | برای Risk R2، سه Mutation survivor را با Testهای هدفمند بررسی کنیم؛ Guardrail زمان نگهداری و false confidence. |
| «ابزار جدید بخریم.» | PoC آفلاین روی Fixture نماینده؛ Exit/rollback و هزینهٔ مهاجرت ثبت شود. |
| «ارتباط بهتر شود.» | یک Handoff contract برای P1/P2؛ completeness و delay با تعریف ثابت بررسی شود. |
| «QA مسئول پیگیری است.» | Experiment steward هماهنگ میکند؛ Scrum Team در Review تصمیم میگیرد. |
قالب Improvement Experiment
experiment: id: E1 hypothesisRef: H1 change: 30-minute daily pair on oldest ready-for-verify item scope: S18, eligible FLOW-v2 items only prediction: median age 4.2h -> 2.5..3.5h baseline: S17 median=4.2 team-hour, n=8 measure: SIG-READY-AGE-v2 + raw distribution guardrail: confirmation rework rate <= baseline + 5pp access/privacy: team aggregate; no individual ranking steward: experiment-steward-a decisionOwner: SCRUM-TEAM-ST17 reviewAt: 2026-08-27T10:00:00Z rollback: access incident or guardrail breach disposition: ADOPT | ADAPT | STOP | EXTEND_WITH_REASON
Measure و Guardrail باید با هم حرکت کنند
اگر تنها Measure کاهش زمان باشد، تیم ممکن است با کوچککردن Scope، حذف بررسی دشوار یا انتقال کار به صف پنهان عدد را بهتر کند. Guardrail پیامد ناخواسته را میبیند: Rework، Evidence gap، WIP بیرون از Workflow، بار شناختی، incident یا دسترسی. هر دو باید همان Window، Population و Policy را داشته باشند.
| هدف محلی | Measure | Guardrail | Countermetric |
|---|---|---|---|
| کاهش صف تأیید | Age distribution | Confirmation rework | آیتمهای خارج از Workflow |
| سریعترشدن Suite | Runtime distribution | Risk/Evidence obligations | Skipped/Quarantined tests |
| بهبود Handoff | Contract completeness | Preparation effort | Shadow chat handoffs |
| افزایش مشارکت Retro | Perspective coverage | Pass/anonymous option | Forced speech/meeting load |
اول Experiment قبلی را Review کنید
جلسهای که هر بار اقدام تازه تولید میکند ولی سرنوشت اقدام قبلی را نمیخواند، Learning backlog میسازد. Review باید Planned change، actual exposure، Evidence، deviations، guardrail، unknown و تصمیم را جدا کند. «انجام شد» معادل «اثر کرد» نیست؛ «اثر همزمان دیده شد» نیز لزوماً رابطهٔ علّی نیست.
experimentReview: experimentId: E0 plannedWindow: S16..S17 actualExposure: 5 of 8 eligible items measureResult: inconclusive guardrailResult: breached on rework deviations: stage outage, item-mix changed unknowns: counterfactual, small population decision: STOP rationale: guardrail breach; mechanism unsupported learningRef: LR-E0-01
Adopt، Adapt، Stop یا Extend؟
| Disposition | شرط | ثبت لازم |
|---|---|---|
| ADOPT | Evidence محدود با Prediction سازگار و Guardrail سالم | Policy/DoD/Workflow change authority |
| ADAPT | Mechanism محتمل، طراحی Experiment ضعیف یا Context تغییرکرده | نسخهٔ تازه و تفاوتها |
| STOP | Guardrail نقض، Hypothesis تضعیف یا هزینه نامتناسب | Learning و rollback |
| EXTEND | Exposure ناکافی و ادامه کمریسک | دلیل، Window تازه و سقف extension |
| ESCALATE | Constraint بیرون اختیار تیم | Authority/Owner/next check/interface |
محدودیت سیستمی را به «تیم بهتر تلاش کند» تبدیل نکنید
اگر Stage مشترک، سیاست دسترسی، Dependency بیرونی، ظرفیت پلتفرم یا تصمیم مدیریتی مسئله است، Scrum Team ممکن است اختیار حل کامل نداشته باشد. یک اقدام داخلی ساختگی، مسئله را پنهان میکند. Constraint را با Evidence، اثر، راهحل موقت، Authority لازم، Owner بیرونی و Next check ثبت کنید؛ همزمان یک Experiment در محدودهٔ اختیار تیم انتخاب کنید.
systemicEscalation: id: ESC-1 constraint: shared-stage-access evidenceRefs: [ENV-E12, O1] teamImpact: blocks accepted evidence for P2 teamWorkaround: bounded local stub, fidelity limitation declared authorityNeeded: platform-owner-a requestedDecision: access window or isolated namespace nextCheck: 2026-08-20 privacy/security: no credential copied into Retro record
نقش تستر در Sprint Retrospective چیست؟
متخصص تست یکی از دیدگاههای لازم دربارهٔ Basis، Data، Environment، Oracle، Evidence، Failure و Flow را میآورد؛ اما مدافع انحصاری کاربر، مالک کیفیت، گزارشگر باگ، تسهیلگر طبیعی یا صاحب راهحل نیست. در زبان Scrum، اگر این متخصص روی ساخت Increment کار میکند در accountability گستردهٔ Developers قرار میگیرد. کیفیت همچنان محصول تعامل کل Scrum Team و سیستم سازمانی است.
| قابلیت تست | مشارکت مفید | مرز |
|---|---|---|
| Evidence literacy | روشنکردن Build/Run/Oracle/limitation | تبدیل Result به حکم کیفیت ممنوع |
| Risk questioning | پرسیدن Counterexample و Unknown | پذیرش Risk اختیار خودکار QA نیست |
| Flow observation | دیدن صف Data/Environment/confirmation | متریک فردی یا QA utilization نسازد |
| Experiment design | Prediction، Fixture و Guardrail | تصمیم تیم را مصادره نکند |
| Failure analysis | Evidence اولیه و Hypothesis رقیب | Retro را جای RCA نگیرد |
برای مرزبندی مسئولیت، راهنمای مالکیت همگانی کیفیت و حق تصمیم را جداگانه ببینید. Shared responsibility نباید به «هیچکس مسئول نیست» یا «QA پاسخگوی همه چیز است» تبدیل شود.
Facilitator صاحب پاسخ نیست
- Purpose، Timebox، Working agreement، privacy boundary و حق Pass را روشن کند.
- Observation را پیش از رأیگیری از Interpretation جدا کند.
- از افراد کمقدرتتر مسیر مشارکت همزمان و ناهمزمان بسازد.
- Hypothesis رقیب و Evidence مخالف را فعالانه دعوت کند.
- Conversation را از شخص به رفتار/شرایط/سیستم برگرداند، بدون پاککردن Accountability.
- در پایان، Experiment/Owner/Review/Decision interface را بخواند؛ نه اینکه خودش Solution را تحمیل کند.
Scrum Master برای اثربخشی Scrum Team پاسخگو و در رفع موانع و تسهیل رویدادها خدمتگزار است، اما راهنمای Scrum الزام نمیکند همیشه Facilitator همین فرد باشد. اگر Scrum Master یا هر عضو دیگری ذینفع مستقیم موضوع است، Facilitation چرخشی یا فرد مورداعتماد میتواند تعارض را کاهش دهد؛ این یک انتخاب Contextual است.
Technique را با Outcome اشتباه نگیرید
| Technique | برای چه مفید است؟ | ریسک | خروجی بعدی |
|---|---|---|---|
| Start/Stop/Continue | جمعآوری سریع رفتارها | Stop میتواند اتهامی شود | Observation validation |
| Sailboat | هدف/باد/لنگر/ریسک | استعارهٔ مبهم | typed records |
| Mad/Sad/Glad | تجربهٔ عاطفی | افشای اجباری | optional self-report |
| Timeline | ترتیب رویداد | توهم علت | competing hypotheses |
| Dot voting | اولویت توجه | قدرت/محبوبیت/تکرار | decision criteria |
| Five Whys | کاوش اولیه | یک زنجیرهٔ علّی ساختگی | RCA اگر لازم است |
رأی، Evidence یا تصمیم نیست
Dot vote میگوید کدام موضوع توجه بیشتری گرفته است؛ نه اینکه Observation درست، Cause قطعی، گزینه کمریسک یا تصمیم مجاز است. رأیها ممکن است با تکرار یادداشت، قدرت اجتماعی، ترتیب ارائه یا غیبت یک دیدگاه منحرف شوند. بعد از رأی، Eligibility، Risk، Authority، Evidence gap، برگشتپذیری و هزینه را بررسی کنید.
چه زمانی Retro را به RCA یا Postmortem وصل کنیم؟
Retro میتواند Signal یک Failure pattern را کشف کند، اما Timebox و Participant scope آن برای تحقیق علّی کامل کافی نیست. برای incident یا defect مهم، یک Investigation با سؤال، Evidence preservation، timeline، فرضیهها، کنترل دسترسی و Owner بسازید و نتیجهٔ معتبرش را بعداً به Experiment برگردانید. راهنمای مستقل تحلیل علت ریشهای از شواهد تا اقدام و Postmortem رخداد بحرانی این عمق را مالکاند.
Defect count ورودی بحث است، نه نمرهٔ QA
تعداد Bug بهتنهایی Exposure، Search effort، Scope، Severity، duplicate، detection phase یا Opportunity را ندارد. افزایش Finding ممکن است از جستوجوی بهتر، تغییر محصول یا خرابی بیشتر آمده باشد. Retro نباید آن را به ارزیابی فرد، اثربخشی QA یا کیفیت محصول تبدیل کند. برای خودِ صف نقص، از پروتکل Triage تا Closure استفاده کنید.
Quality و Effectiveness را عملیاتی اما محدود تعریف کنید
| عبارت | پرسش عملیاتی | Claim مجاز | Claim ممنوع |
|---|---|---|---|
| کیفیت | کدام Risk/Outcome/Evidence/DoD؟ | Evidence obligation R2 زودتر فراهم شد | کیفیت ۲۰٪ بالا رفت |
| اثربخشی | برای کدام Goal و trade-off؟ | صف محلی طبق تعریف v2 کاهش یافت | تیم مؤثرتر شد |
| یادگیری | کدام Hypothesis تغییر کرد؟ | H1 تضعیف و E1 متوقف شد | فرهنگ یادگیری ساخته شد |
| امنیت روانی | چه امکان/ریسک گفتوگویی؟ | کانال Pass و anonymous فراهم شد | جلسه کاملاً امن بود |
تغییر Definition of Done یک ویرایش بیصدا نیست
Retro ممکن است نیاز به تغییر DoD را آشکار کند، اما تیم باید استانداردهای سازمانی، سطح اختیار، اثر روی Incrementهای آینده، توان اجرا، Transition و تاریخ مؤثر را بررسی کند. حذف یک کنترل برای «سریعترشدن» یا افزودن ده الزام بدون ظرفیت، هر دو میتوانند Transparency را خراب کنند. Proposal، approver/authority، effective version و migration را ثبت کنید.
بهبود را در Sprint Backlog مرئی کنید
راهنمای Scrum اجازه میدهد اثرگذارترین بهبودها به Sprint Backlog بعدی افزوده شوند. این به معنی سهمیهٔ ثابت، Story Point اجباری یا تعهد به همهٔ Actionها نیست. Work لازم—آمادهسازی Fixture، اجرای Experiment، جمعآوری داده، Review و rollback—را در Plan قابلمشاهده کنید تا «کار واقعی محصول» آن را پنهان نکند. انتخاب نهایی Sprint Backlog مطابق مسئولیت Developers در Sprint Planning شواهدمحور باقی میماند.
مرز Retro با Daily Scrum و Feedback
| Signal | همین امروز | در Retro | مسیر تخصصی |
|---|---|---|---|
| Blocker جاری | Plan را در Daily تطبیق دهید | Pattern/شرایط را بررسی کنید | Escalation |
| Evidence gap | Pair/Swarm/Re-sequence | Mechanism و policy را آزمایش کنید | Test strategy/DoD |
| Feedback بینفردی | اگر امن است مستقیم Repair کنید | Pattern تیمی، نه محاکمه | Confidential support |
| Defect بحرانی | Triage/containment | Learning interface | RCA/Postmortem |
برای حلقهٔ روزانه، Daily Scrum مبتنی بر Evidence Flow و برای ادعای بینفردی، Feedback از Claim تا Repair را ببینید. نگهداشتن همهٔ تنشها تا پایان Sprint، بازخورد را کند و ریسک را بیشتر میکند.
آزمایش تکرارپذیر: آیا یادداشت، رأی و Owner کافی است؟
Fixture کاملاً ساختگی SYN-SPRINT-RETRO-EXPERIMENT-01 هشت یادداشت، هشت رأی و سه Action دارای Owner/Due دارد؛ کنترل سطحی `PASS` میدهد. Validator مستقل سپس Baseline، Observation، Hypothesis، Experiment، Guardrail، Review و Escalation را بررسی میکند. داده به تیم، شرکت یا ابزار واقعی مربوط نیست.
Fixture معیوب در برابر Contract
| بعد | Contract | Draft |
|---|---|---|
| Sprint/Goal | S17/SG-17 | S16/SG-16 |
| Backlog/DoD/Workflow | SB-D4/DOD-v4/FLOW-v2 | SB-D2/DOD-v3/FLOW-v1 |
| Cutoff/participants | صریح | خالی |
| Observation | Source/time/definition/population | Cause، فرد، duplicate و O99 |
| Hypothesis | Links/falsifier/PLAUSIBLE | بدون Link، PROVEN |
| Experiment E1 | Prediction/baseline/measure/guardrail/rollback/review | «افزایش پوشش» |
| Experiment E2 | کوچک و برگشتپذیر | خرید ابزار/حذف فرایند |
| Closure | Prior review + escalation | هردو غایب |
خروجی اجرای مستقل Validator
fixture: SYN-SPRINT-RETRO-EXPERIMENT-01 runtime: Node.js v26.7.0 superficial: PASS | notes=8 | votes=8 | actions=3 auditedDraft: HOLD findings (31): 1 wrong-sprint:S16->S17 2 wrong-sprint-goal:SG-16->SG-17 3 stale-sprint-backlog:SB-D2->SB-D4 4 stale-dod:DOD-v3->DOD-v4 5 stale-workflow:FLOW-v1->FLOW-v2 6 missing-facts-cutoff 7 missing-participant-scope 8 O1-missing-source 9 O1-missing-observed-at 10 O1-observation-asserts-cause 11 O2-missing-signal-definition 12 O2-missing-population 13 O2-unsafe-individual-attribution 14 duplicate-observation:O2 15 duplicate-O2-missing-source 16 unknown-observation:O99 17 H1-missing-observation-links 18 H1-missing-falsifier 19 H1-anecdote-marked-proven 20 E1-missing-prediction 21 E1-missing-baseline 22 E1-missing-measure 23 E1-missing-guardrail 24 E1-missing-rollback-trigger 25 E1-missing-review-date 26 E1-missing-decision-owner 27 E2-solution-without-hypothesis 28 E2-irreversible-change 29 E2-missing-stop-condition 30 prior-experiment-not-reviewed 31 systemic-constraint-not-escalated corrected: READY_FOR_EXPERIMENT_REVIEW | findings=0
نسخهٔ اصلاحی چه چیزی را درست کرد؟
نسخهٔ اصلاحی S17/SG-۱۷/SB-D4/DOD-v4/FLOW-v2 و Cutoff/Participant scope را قفل کرد؛ O1/O2 را با Source، زمان، تعریف و Population ثبت کرد؛ نسبتدهی فردی و Cause قطعی را حذف کرد؛ H1 را `PLAUSIBLE` با Falsifier نگه داشت؛ E1 را به Pair window سیدقیقهای، Prediction ۲.۵..۳.5h، Baseline ۴.۲ team-hour، Measure ثابت، Rework guardrail، rollback و Review date وصل کرد؛ E0 را `STOP` و Constraint دسترسی را `ESC-۱` کرد.
`READY_FOR_EXPERIMENT_REVIEW` فقط میگوید رکورد ساختاری برای بازبینی آماده است. این نتیجه صحت Source، کفایت Population، رابطهٔ علّی، بهترشدن تیم، افزایش کیفیت، امنیت روانی، موفقیت Sprint یا مناسببودن تصمیم را اثبات نمیکند. دو نقص نخست Validator که حین توسعه پیدا و اصلاح شدند نیز یادآوری میکنند خودِ کنترلها باید با Fixture سالم و معیوب آزموده شوند.
آزمایشگاه فارسی و آفلاین برای تیم ایرانی
دامنهٔ تمرینی یک Checkout خیالی و کاملاً جدا از شبکه است: Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification. سناریوهای timeout پیش/پس از commit ساختگی، retry، callback تکراری/دیر/جابجا، اختلاف نمایش IRR/تومان، رقم فارسی/عربی/لاتین، Unicode و RTL/LTR فقط Fixture آموزشیاند. هیچ شرکت، کاربر، پرداخت، بانک، PSP، حساب یا پول واقعی در کار نیست.
| کنترل | قاعدهٔ Lab |
|---|---|
| Identity | Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence جدا |
| Money | IRR خیالی Canonical؛ تومان فقط View صریح |
| Digits/RTL | مقایسهٔ فارسی/عربی/لاتین و کنترل bidi |
| Time | UTC instant + Asia/Tehran view؛ جلالی فقط Presentation |
| Network | کاملاً disconnected؛ PSP Stub محلی |
| Secrets | بدون PAN/CVV2/OTP/cookie/token/credential |
| People | بدون نام/موبایل/ایمیل/IP واقعی |
| Claim | بدون ادعای بانکی/مالی/حقوقی/مالیاتی/امنیتی/حریم خصوصی ایران |
نمونهٔ Experiment در Checkout ساختگی
| فیلد | مقدار خیالی |
|---|---|
| Observation | برای ۳ از ۸ Attempt، Reconciliation Evidence دیرتر از Window محلی ثبت شد |
| Hypothesis | نامشخصبودن Event/Attempt correlation شروع بررسی را عقب میاندازد |
| Experiment | نمایش correlation ID ساختگی در Harness برای یک Sprint |
| Prediction | median locate-time از ۱۸ به ۱۰..۱۴ دقیقه |
| Guardrail | هیچ Secret/PII وارد Evidence نشود؛ false-match افزایش نیابد |
| Stop | privacy breach، false-match یا نبود تغییر در Window |
| Claim limit | فقط دربارهٔ Fixture محلی؛ نه Production یا تیم واقعی |
Retro راه دور و Async بدون حذف صداهای کمقدرت
- Prompt و Baseline را پیشاپیش بدهید، اما Noteها را قبل از Window توافقشده تحلیل نکنید.
- ورودی ناشناس را فقط اگر ابزار و فرایند واقعاً anonymity را حفظ میکنند «ناشناس» بنامید؛ pseudonymous را اشتباه معرفی نکنید.
- روش Text، صوت، Caption، keyboard-only و زمان فکرکردن مستقل فراهم کنید؛ ویدئو را اجباری نکنید.
- رأیهای Async را با Participant scope و cutoff ثبت کنید و دیدگاه غایب را Unknown نگه دارید.
- Decision را در کانال خصوصی گم نکنید؛ Experiment record و Review date باید مقصد مشترک داشته باشد.
دسترسیپذیری، امنیت و حریم خصوصی Retro
| ریسک | کنترل |
|---|---|
| رنگ تنها معنای رأی/گروه | Label، Pattern و متن جایگزین |
| تختهٔ غیرقابل keyboard | Outline/Table معادل و ترتیب Focus |
| اسکرینشات Dashboard | کمینهسازی و Redaction؛ ترجیح Record ساختاری |
| ذخیرهٔ شکایت شخصی | Purpose/Access/Retention/Deletion روشن |
| Secret در Log/Note | Reference امن، نه Copy |
| Export به Vendor | Data classification و قرارداد/محل داده |
| Retention بیانتها | Expiry و Learning record کمینه |
AI در Retrospective: دستیار طبقهبندی، نه داور تیم
AI میتواند با دادهٔ مجاز، خلاصهٔ پیشنهادی، duplicate candidate، Hypothesis رقیب یا missing-field بسازد. نباید احساس، قصد، مقصر، عملکرد فرد، Cause یا «سلامت تیم» را استنتاج کند. متن ورودی/خروجی، مدل/نسخه، زمان، دسترسی، redaction و reviewer را ثبت کنید؛ Raw note حساس را بیاجازه به سرویس بیرونی نفرستید؛ و هر Participant باید بتواند نسبت به خلاصهٔ منتسب به خود Correction بخواهد.
نقشها و حق تصمیم در حلقهٔ بهبود
| Capability/Accountability | کار | حق تصمیم محدود |
|---|---|---|
| Scrum Team | Inspect و انتخاب بهبود | Experiment در اختیار تیم |
| Developers | Plan و Sprint Backlog | نحوهٔ اجرای Work |
| Product Owner | Product Goal/Backlog context | Product Backlog ordering |
| Scrum Master | اثربخشی Scrum/رفع مانع/Facilitation | نه حکم Cause یا ارزیابی فرد |
| Experiment steward | هماهنگی Exposure/Evidence/Review | نه مالک انحصاری Improvement |
| External authority | Constraint سازمانی | مطابق Governance |
| HR/Security/Legal | مسیر تخصصی حساس | خارج از رأی Retro |
متریکهای سلامت Retro و Countermetricها
| متریک | تعریف | Countermetric/هشدار |
|---|---|---|
| Closure rate | Experimentهای دارای Disposition / واجد Review | بستهشدن صوری |
| Observation lineage | Observationهای دارای Source/Context | بوروکراسی و حذف self-report |
| Hypothesis diversity | موضوعهای دارای توضیح رقیب | تولید مصنوعی گزینه |
| Guardrail completeness | Experimentهای دارای پیامد جانبی | Guardrail بیمعنا |
| Experiment WIP | بهبودهای فعال همزمان | کمبود یادگیری یا overload |
| Perspective coverage | نوع دیدگاههای حاضر/غایب | اجبار به حرفزدن |
| Escalation age | زمان تا پاسخ Authority | رتبهبندی فردی |
هیچیک KPI بهرهوری فردی یا نمرهٔ تیم نیست. مقایسهٔ تیمها با Closure rate یا تعداد Action، زمینه و سختی Constraint را حذف و Gaming ایجاد میکند. برای سوگیری مخرج، Proxy و Goodhart، راهنمای تلههای معیارهای تست را جداگانه استفاده کنید.
۲۸ ضدالگوی Sprint Retrospective
- QA Retro جدا از Scrum Team برای مسائل مشترک
- تستر بهعنوان مالک کیفیت یا مدافع انحصاری کاربر
- سه سؤال بهعنوان قانون Scrum
- یک قالب ثابت برای هر Context
- تعداد Note/رأی بهعنوان موفقیت
- Dot vote بهعنوان Evidence
- رأی اکثریت بهعنوان Cause
- نسبتدادن Signal تیمی به فرد
- آوردن Performance review به Retro
- Observation بدون Source/زمان
- Timeline بهعنوان اثبات علت
- Five Whys با یک زنجیرهٔ قطعی
- حل Incident پیچیده در Timebox Retro
- هدف پوشش تست بدون Risk/Population
- Bug count بهعنوان نمرهٔ QA
- Action بدون Hypothesis
- Action بدون baseline/prediction
- Experiment بدون guardrail
- تغییر برگشتناپذیر بهعنوان آزمایش
- Owner بهعنوان مقصر
- سه اقدام تازه بدون Review قبلی
- Done شدن Action برابر اثرگذاری
- پنهانکردن Constraint بیرون تیم
- تغییر خاموش DoD/Workflow
- اجبار ویدئو یا صحبتکردن
- ادعای anonymity کاذب
- ورود Note حساس به AI/Vendor
- ادعای تضمین کیفیت، فرهنگ یا امنیت روانی
Pilot سیروزه برای تبدیل Action به Experiment
| بازه | کار | Exit محدود |
|---|---|---|
| روز ۱–۳ | Purpose، privacy، Baseline و prior actions | Contract مرورشده |
| روز ۴–۷ | Observation Registry روی یک Sprint | Source/Unknown/duplicate روشن |
| روز ۸–۱۰ | دو Hypothesis رقیب و Option | Falsifier و authority روشن |
| روز ۱۱–۲۴ | یک Experiment کوچک | Exposure/Measure/Guardrail ثبت |
| روز ۲۵–۲۷ | Review Evidence و deviations | بدون quality claim |
| روز ۲۸–۳۰ | Adopt/Adapt/Stop/Escalate | Learning record و next check |
Pilot موفق یعنی تیم یک حلقه را با Records قابلبازبینی بسته و مضرات را دیده است؛ نه اینکه عددی الزاماً بهتر شود. اگر هزینهٔ ثبت از ارزش تصمیم بیشتر است، Contract را کوچک کنید. اگر موضوع حساس است، Pilot را متوقف و مسیر امنتری انتخاب کنید.
چکلیست بازبینی Retrospective Experiment
- Purpose/Retro/Sprint/Goal/Backlog/DoD/Workflow/Cutoff/participant scope نسخهدار است.
- Experiment قبلی Evidence، deviation، guardrail و Disposition دارد.
- Observation از Interpretation، Cause، Judgment و Solution جداست.
- Source/time/context/population/limitation و Unknown ثبت شدهاند.
- duplicate، missing perspective و Correction قابلردیابیاند.
- دادهٔ فردی کمینه و از ارزیابی عملکرد جداست.
- حق Pass، مسیر Async، accessibility و confidential escalation روشن است.
- حداقل یک Hypothesis رقیب و Falsifier وجود دارد.
- Option در اختیار تیم است یا Escalation interface دارد.
- Experiment کوچک، محدود، برگشتپذیر و دارای Prediction است.
- Measure تعریف ثابت، Baseline، Population، Unit و Window دارد.
- Guardrail، rollback/stop و پیامد جانبی روشناند.
- Steward، decision owner، review date و Backlog reference ثبتاند.
- Adopt/Adapt/Stop/Extend/Escalate با Evidence محدود تصمیم میشود.
- نتیجه ادعای علت، کیفیت، عملکرد فرد، Sprint success یا امنیت روانی نمیسازد.
- Secret/PII/log/screenshot خام و AI inference نامجاز وارد Record نشده است.
- تغییر DoD/Policy فقط با Authority و نسخهٔ مؤثر اعمال میشود.
- Learning record نگهداری/دسترسی/حذف معین دارد.
نقشهٔ مطالعهٔ مرتبط
برای محصول و ذینفعان از Sprint Review، برای Plan روزانه از Daily Scrum، برای Scope اولیه از Sprint Planning، برای Defect از Triage، برای Cause از RCA/Postmortem، برای ادعای بینفردی از Feedback protocol و برای انگیزه/ساختار سازمانی از راهنمای فرهنگ کیفیت بهعنوان سیستم رفتار و مشوق استفاده کنید. Retro باید Interface این کارها را نگه دارد، نه اینکه همه را در یک جلسه ادغام کند.
پرسشهای متداول
آیا سه سؤال «چه خوب بود، چه بد بود، چه کنیم» در Scrum الزامی است؟
خیر. Scrum Guide هدف، موضوع بازرسی، Timebox و جایگاه Retrospective را مشخص میکند، نه این سه سؤال یا قالب Start–Stop–Continue. تیم میتواند Technique را متناسب با Context عوض کند؛ معیار بهتر این است که Observation معتبر، Hypothesis قابلبررسی و Improvement قابلپیگیری تولید شود.
آیا مدیر میتواند در Sprint Retrospective حاضر باشد؟
Retrospective رویداد Scrum Team است و Scrum Guide قانون عام «مدیر هرگز حاضر نباشد» ندارد. اگر مدیر عضو Scrum Team نیست، Purpose، رضایت تیم، اثر قدرت و محرمانگی باید پیش از دعوت روشن شود. برای موضوع حساس یا ارزیابی عملکرد، مسیر جدا مناسبتر است؛ حضور یک عنوان شغلی بهتنهایی امنیت یا ناامنی را اثبات نمیکند.
چند Action Item باید از هر Retro خارج شود؟
عدد جهانی وجود ندارد. ظرفیت یادگیری، ریسک و WIP مهمتر از سهمیه است. اغلب یک Experiment کوچک با Owner، Prediction، Guardrail و Review date از چند Action همزمان قابلآموختنتر است. ابتدا Experiment قبلی را ببندید و سپس Work تازه را در Sprint Backlog مرئی کنید.
آیا افزایش Code Coverage هدف خوبی برای Retro است؟
بهتنهایی نه. درصد باید Population، ابزار، exclusion و Risk rationale داشته باشد و قدرت Oracle یا رفتار مهم را اثبات نمیکند. بهجای «۶۰ به ۷۵٪»، یک Risk/Evidence gap مشخص را با Test design یا Mutation survivor هدف بگیرید و Guardrail هزینهٔ نگهداری و false confidence را ثبت کنید.
اگر تیم دربارهٔ علت اختلاف دارد، جلسه شکست خورده است؟
خیر. اختلاف میتواند Unknown واقعی را آشکار کند. Observation مشترک را ثبت، Hypothesisهای رقیب و Evidence تفکیککننده را تعریف کنید و یک Experiment برگشتپذیر بسازید. رأیگیری برای قطعیکردن Cause مناسب نیست؛ اگر ریسک یا عمق بالاست، Investigation یا RCA جدا لازم است.
جمعبندی: Retro باید حلقهٔ یادگیری را ببندد
Sprint Retrospective با تختهٔ زیبا، رأی زیاد یا Action ownerدار موفق نمیشود. Baseline درست را قفل کنید؛ Observation، Interpretation و Cause را جدا نگه دارید؛ تجربهٔ انسانی را با نوع Source و محدودیتش حفظ کنید؛ Hypothesis رقیب بسازید؛ یک Improvement کوچک را با Prediction، Measure، Guardrail و rollback آزمایش کنید؛ Constraint بیرون تیم را Escalate کنید؛ و در موعد معین Adopt، Adapt یا Stop بگویید. این حلقه کیفیت و اثربخشی را تضمین نمیکند، اما ادعاها و تصمیمهای بهبود را قابلبازبینی و یادگیری را قابلپیگیری میسازد.
