تستر در Daily Scrum؛ از گزارش فردی تا Evidence Flow

Daily Scrum زمانی بی‌اثر می‌شود که هر نفر رو به مدیر بگوید دیروز چه کرد، امروز چه می‌کند و چه مانعی دارد؛ سپس همه با همان برنامهٔ قبلی برگردند. کامل‌بودن گزارش‌های فردی نشان نمی‌دهد Sprint Goal جلو رفته، کار واقعاً جریان دارد، Evidence روی Build هدف معتبر است یا برنامه برای دادهٔ تازه سازگار شده است. پرسش اصلی رویداد این است: با آنچه تا این لحظه مشاهده کرده‌ایم، برنامهٔ Developers برای نزدیک‌شدن به Sprint Goal در روز پیش رو چگونه باید تغییر کند؟

این راهنما نقش قابلیت تست در Daily Scrum را به‌صورت یک حلقهٔ بازرسی Evidence و Flow طراحی می‌کند. هدف، نمایش ارزش QA یا گزارش تعداد باگ نیست؛ هدف آشکارکردن فاصلهٔ Goal تا Evidence، سن و انسداد کار، تغییر Risk/Dependency و ساخت یک برنامهٔ عملی برای روز بعد است. گفت‌وگوی تشخیصی طولانی، Triage نقص و Blocker resolution می‌تواند بلافاصله پس از رویداد با افراد مرتبط ادامه یابد.

پاسخ کوتاه: Daily Scrum شواهدمحور چه می‌کند؟

Sprint Goal + current Sprint Backlog
  -> fresh observations and accepted evidence
  -> inspect progress, flow, risk and unknowns
  -> identify deviation, aging work and blockers
  -> choose today's adaptations
  -> assign focused follow-ups
  -> update Sprint Backlog
  -> inspect again as new facts emerge

خروجی خوب یک «Actionable plan برای روز آینده» است: چه کاری را تمام کنیم، چه کاری را شروع نکنیم، کجا Swarm/Pair کنیم، کدام Evidence را زودتر بسازیم و چه Follow-upی با چه Owner/زمانی لازم است. Daily Scrum تنها زمان Adaptation نیست؛ Developers می‌توانند هر زمان لازم شد برنامه را تغییر دهند.

Daily Scrum در راهنمای رسمی Scrum

عنصر	تعریف رسمی	برداشت نادرست
Purpose	بازرسی پیشرفت به Sprint Goal و تطبیق Sprint Backlog	Status report به مدیر
Participants	رویداد ۱۵ دقیقه‌ای Developers	جلسهٔ گزارش همهٔ ذی‌نفعان
Structure	ساختار و تکنیک در اختیار Developers	سه سؤال اجباری
Outcome	Actionable plan برای روز بعد	صورت‌جلسهٔ فعالیت گذشته
Adaptation	تغییر Sprint Backlog در صورت نیاز	برنامهٔ Sprint تغییرناپذیر
Follow-up	بحث تفصیلی می‌تواند در طول روز انجام شود	حل همهٔ مسائل در ۱۵ دقیقه

راهنمای Scrum ۲۰۲۰ سه سؤال قدیمی را الزام نمی‌کند. Daily Scrum برای Developers است؛ Product Owner یا Scrum Master تنها وقتی روی Sprint Backlog فعالانه کار می‌کنند، به‌عنوان Developers شرکت می‌کنند. Scrum Master رویداد را برای Developers اداره یا گزارش را جمع نمی‌کند. منبع: Scrum Guide 2020.

آیا Tester باید در Daily Scrum باشد؟

Scrum عنوان مستقل Tester را تعریف نمی‌کند. اگر متخصص تست عضو Scrum Team است و در ساخت Increment مشارکت دارد، در واژگان ساده‌شدهٔ Scrum جزو Developers است و در Daily Scrum شرکت می‌کند. اگر یک واحد تست بیرونی، Auditor یا مشاور است، الزام خودکار به شرکت ندارد؛ اطلاعات یا همکاری لازم باید از مسیر مناسب فراهم شود، بدون تبدیل رویداد به جلسهٔ Status برون‌تیمی.

Context	حضور/تعامل	خطر
Testing capability داخل Developers	عضو کامل با مالکیت مشترک Plan	گزارش به «توسعه‌دهندگان» به‌جای همکاری
Specialist دعوت‌شده	Advice در صورت نیاز، سپس Follow-up	تجویز How به Developers
Independent test team	Interface/Dependency/Update قراردادی	جلسهٔ هماهنگی چندتیمی در Daily
Manager/stakeholder observer	فقط اگر حضور، self-management را مختل نکند	Status theatre و خودسانسوری
Product Owner/Scrum Master	اگر فعالانه روی items کار می‌کنند، به‌عنوان Developers	مدیریت نوبت گزارش

مرز مالکیت با Sprint Planning و Status Update

Artifact/رویداد	پرسش	مالک خوشه
Sprint Planning	Why/What/How آغاز Sprint چیست؟	برنامه‌ریزی شواهدمحور Sprint
Daily Scrum	با Evidence امروز، How فردا چگونه Adapt شود؟	همین مقاله
Status/Blocker update	چه Claim/Actionی به مخاطب دیگری ارسال شود؟	Update و Blocker Packet
Test execution	Attempt/Outcome/Evidence چگونه کنترل شود؟	چرخه اجرای تست
Defect triage	نقص چگونه ارزیابی/اولویت/Disposition شود؟	مدیریت نقص

Daily Scrum می‌تواند نیاز به Update، Triage یا جلسهٔ فنی را آشکار کند، اما جای آن‌ها نیست. به‌جای بازکردن Log و حل Root cause در Timebox، یک Follow-up دقیق بسازید و Developers روی سازگاری Plan تصمیم بگیرند.

Daily Inspection Contract

DailyInspection {
  sprint_id, sprint_goal_id,
  sprint_backlog_snapshot,
  definition_of_done_version,
  workflow_policy_version,
  facts_as_of, timezone,
  current_increment_ref,
  item_flow_snapshots[],
  accepted_evidence_refs[],
  risk_and_unknown_deltas[],
  blocker_refs[],
  goal_progress_claim,
  adaptations[], follow_ups[],
  resulting_backlog_snapshot
}

این Contract الزام Scrum نیست؛ یک قالب آموزشی برای جلوگیری از بازرسی نسخه‌های متفاوت است. Board زنده اگر Cutoff، DoD و Workflow policy نداشته باشد، ممکن است دادهٔ تازه‌نما اما ناسازگار نشان دهد.

از Sprint Goal شروع کنید، نه از نفر اول

• Goal و تغییر Context از بازرسی قبل چیست؟
• کدام Evidence تازه Contribution یا فرض Goal را پشتیبانی/رد می‌کند؟
• کدام بخش Goal بیشترین فاصله یا Unknown را دارد؟
• کدام Work item نزدیک‌ترین مسیر به Increment Done است؟
• چه چیزی Flow یا Evidence را متوقف کرده است؟
• با ظرفیت امروز، چه Adaptation بیشترین یادگیری/پیشرفت به Goal می‌دهد؟

Walk-the-board یا Walk-the-goal معمولاً وابستگی‌ها و WIP را بهتر از Round-robin فردی نشان می‌دهد. تیم می‌تواند ساختار دیگری انتخاب کند؛ معیار، تمرکز بر Goal و خروجی عملی است، نه اجرای یک مراسم خاص.

سه سؤال فردی چه چیزی را پنهان می‌کند؟

گزارش	اطلاعات موجود	اطلاعات پنهان
دیروز P1 را تمام کردم	Activity/ادعای State	Build، DoD، Evidence و Contribution
امروز P2 را تست می‌کنم	قصد فرد	اولویت Goal، Data، Environment و Pairing
Environment مشکل دارد	Signal کلی	blocked work، اثر، Owner و Next check
مانعی ندارم	برداشت فرد	Aging، Queue، Dependency و Unknown تیم
یک باگ Critical پیدا شد	Label	Observation، Triage، Goal effect و action

سه سؤال می‌تواند Mnemonic اختیاری باشد، اما اگر پاسخ‌ها به Plan adaptation نرسند، Purpose محقق نشده است. «همه صحبت کردند» Metric موفقیت Daily Scrum نیست.

Evidence Flow را کنار Work Flow ببینید

Work item selected
 -> basis/risk clarified
 -> data/environment ready
 -> thin implementation
 -> executable observation
 -> outcome + evidence
 -> defect/fix/confirmation if needed
 -> integrated evidence against DoD
 -> usable Increment

کارت می‌تواند در ستون «Done» باشد، ولی Evidence لازم روی Build هدف ناقص یا stale باشد. برعکس، یک Experiment می‌تواند Evidence ارزشمندی بسازد بی‌آنکه Feature Done باشد. Work state و Evidence state را جدا اما مرتبط نگه دارید.

Item Inspection Snapshot

ItemInspection {
  item_id, goal_contribution,
  current_state, started_at, age,
  build_id, environment_id,
  dod_obligations[],
  required_evidence[], accepted_evidence[],
  unknowns[], blocker_ids[],
  current_owner_or_pair,
  next_evidence_step,
  options_to_improve_flow[]
}

Owner در اینجا مسئول هماهنگی فعلی است، نه مالک انحصاری PBI. اگر کارت بدون Next evidence step است، گفتن «ادامه می‌دهم» Plan قابل اقدام نمی‌سازد.

Done ادعایی را با DoD و Build تطبیق دهید

ادعا	کنترل	Adaptation نمونه
Code complete	کدام DoD obligation باقی است؟	Pair برای integration evidence
Test passed	Attempt/Build/Data/Oracle/Evidence چیست؟	Rerun روی B17
Defect fixed	Confirmation و regression impact؟	fix+confirm slice
Automation done	CI stability/diagnostic/maintenance؟	quarantine investigation
Documentation done	Source/Freshness/reviewer؟	review/correction
PBI Done	Increment usable و DoD کامل؟	بازگشت به active، نه سبز نمایشی

Facts-as-of و Build mismatch را پنهان نکنید

نتیجهٔ دیروز روی B16 نمی‌تواند بدون Reuse rule وضعیت B17 را سبز کند. Dashboard ساعت ۹ ممکن است داده‌ها را فقط تا ساعت ۶ داشته باشد. در Daily Scrum لازم نیست Metadata را بلند بخوانید، اما View باید Cutoff و Build را نشان دهد و mismatch را علامت بزند. برای طراحی Freshness و Drift، مستندات تست زنده را ببینید.

Risk delta را به Plan delta تبدیل کنید

Signal تازه	Risk delta	Adaptation احتمالی
DB schema تغییر کرده	Migration/report/reconciliation uncertainty	Impact map + evidence slice
Callback تکراری دیده شد	Idempotency consequence	Stop new work؛ reproduce/fix/confirm
Environment stale	Evidence validity پایین	restore/fallback/claim limitation
Accessibility path blocked	DoD/usable Increment gap	Pair UI+testing capability
Dependency تأخیر دارد	Forecast/sequence change	Swarm، fake یا Scope negotiation
Goal assumption رد شد	Value hypothesis invalid	Product Owner conversation/Goal check

گفتن «Regression لازم است» بدون Scope و Evidence obligation کافی نیست. Risk signal را به سؤال، کار، Owner و نقطهٔ بازرسی تبدیل کنید. برای تحلیل کامل Risk، راهنمای تست مبتنی بر ریسک مرجع است.

Flow metrics مکمل اختیاری Scrum هستند

Metric	تعریف قراردادی	مصرف Daily	خطر
WIP	آیتم بین Start/Finish workflow	آیا کار تازه را متوقف کنیم؟	شمردن Taskهای ناهمگون
Work Item Age	زمان سپری‌شده برای آیتم ناتمام	کدام کار aging/stuck است؟	Threshold جهانی
Cycle Time	Start تا Finish آیتم تمام‌شده	Context Forecast	میانگین بدون distribution
Throughput	تعداد تمام‌شده در واحد زمان	تاریخچهٔ Flow	Velocity game/ریزکردن مصنوعی

Kanban یک مکمل اختیاری برای بهینه‌سازی Flow است، نه بخش اجباری Scrum. Metric بدون تعریف Start/Finish، Work item type، Window و Policy معنای کافی ندارد. منبع رسمی مستقل: The Kanban Guide.

Definition of Workflow محلی

WorkflowPolicy {
  version,
  work_item_types[],
  started_definition,
  finished_definition,
  states[],
  wip_controls[],
  blocked_policy,
  evidence_state_mapping,
  service_level_expectation_optional,
  review_triggers[]
}

Board column نام Policy نیست. اگر «Testing» هم صف، هم فعالیت و هم Outcome را نشان دهد، Flow قابل تفسیر نیست. می‌توان Workflow ساده داشت؛ شرط آن است که تیم معنای مشترک و نسخهٔ فعال را بداند.

Work Item Age را با Context بخوانید

• آیتم از چه زمان و طبق کدام Start definition آغاز شده؟
• اکنون در کدام State و Queue است؟
• آیا active work است یا waiting/blocked؟
• چقدر به Finish و Evidence لازم نزدیک است؟
• Comparable history و SLE محلی چه می‌گوید؟
• با Finish‌کردن آن چه WIP/Goal/Evidence آزاد می‌شود؟

Age بالا خودکار به معنی مشکل یا Priority بالا نیست. Age پایین نیز Flow سالم را ثابت نمی‌کند. Metric برای Conversation و تصمیم است، نه امتیاز عملکرد فردی.

Stop starting، start finishing—با مرز Goal

وقتی چند آیتم نیمه‌تمام و Evidence gap داریم، شروع PBI تازه معمولاً صف را بزرگ می‌کند. تیم می‌تواند Swarm روی نزدیک‌ترین مسیر Goal، Pair برای Oracle/Automation، رفع Environment یا تکمیل Integration کند. این یک شعار مطلق نیست: گاهی Dependency خارجی اجازهٔ Finish نمی‌دهد یا Experiment تازه بیشترین یادگیری را دارد؛ تصمیم را با Goal، Risk و Flow بگیرید.

Swarming و Pairing را عملی تعریف کنید

مسئله	ترکیب قابلیت	خروجی زمان‌دار
Oracle مبهم	Domain + testing + development	Rule/Example/Decision ref
Environment blocked	Ops + affected developer	readiness evidence/fallback
Failure سخت	Developer + testing capability	reproduction/fix hypothesis
Accessibility gap	UI + accessibility capability	integrated keyboard evidence
Automation flaky	Maintainer + system owner	classification/containment
Reconciliation gap	Data/domain/testing	independent comparison

Swarm به معنی افزودن همه به یک تماس نیست. سؤال، Scope، Timebox و Expected output تعیین کنید و WIP تازه را محدود کنید.

Blocker را دقیق اما کوتاه وارد Daily کنید

BlockerSignal {
  blocker_id,
  blocked_work_or_evidence,
  observation,
  direct_impact_on_goal_or_plan,
  response_owner,
  next_check,
  immediate_plan_option,
  follow_up_uri
}

در Daily بگویید «BL-ENV-۱ تولید EP-RECONCILIATION برای P2 را متوقف کرده؛ Env owner تا ۱۱:۳۰ بررسی می‌کند؛ امروز P4 را شروع نمی‌کنیم و دو نفر روی offline evidence محدود کار می‌کنند.» Root cause و Log در Follow-up. بستهٔ کامل در راهنمای Blocker Packet آمده است.

Impediment، Defect، Risk و Blocked evidence

نوع	Daily سؤال	Follow-up مالک
Defect	اثر آن بر Goal/Plan/DoD چیست؟	Defect workflow/triage
Impediment	چه چیزی پیشرفت تیم را مختل کرده؟	طبق Context؛ Scrum Master removal را enable می‌کند
Dependency	کدام شرط/موعد/Owner در خطر است؟	Dependency owner
Product risk	چه Evidence/Adaptation تازه لازم است؟	Risk/evidence work
Blocked attempt	کدام Attempt چرا معتبر نیست؟	Run/Environment owner
Unknown	کدام تصمیم/Forecast محدود شده؟	Spike/question owner

Follow-up Contract بعد از Daily

DailyFollowUp {
  follow_up_id, trigger,
  question_or_outcome,
  required_people_or_capabilities[],
  owner, due_at, timebox,
  source_refs[],
  decision_or_evidence_destination,
  next_inspection
}

«بعداً صحبت می‌کنیم» Follow-up نیست. Owner، سؤال، افراد لازم، زمان و محل ثبت نتیجه را مشخص کنید. همهٔ Developers لازم نیست در تمام After-partyها بمانند.

Actionable Adaptation Record

PlanAdaptation {
  adaptation_id,
  observation_and_evidence,
  affected_goal_or_items[],
  chosen_change,
  alternatives_considered[],
  work_stopped_or_not_started[],
  work_swarmed_or_resequenced[],
  owners_or_pairs[],
  expected_next_evidence,
  inspect_at,
  sprint_backlog_change_ref
}

Adaptation می‌تواند تغییر ترتیب، Pair/Swarm، کاهش WIP، افزودن کار Evidence، مذاکرهٔ Scope با Product Owner یا اصلاح Plan باشد. Sprint Goal نباید به‌خطر بیفتد؛ Scope می‌تواند با یادگیری روشن‌تر و با Product Owner مذاکره شود.

نمونهٔ گزارش فردی را به Conversation تیمی تبدیل کنید

قبل	بعد
دیروز P1 را تست کردم.	Evidence عملکردی P1 روی B17 پذیرفته شد؛ مسیر پایهٔ Goal اکنون شاهد دارد.
امروز P2 را تست می‌کنم.	P2 چهار روزه است و Reconciliation blocked؛ پیشنهاد: شروع P4 متوقف و دو نفر روی BL-ENV-۱/EP-REC swarm کنند.
Environment خراب است.	BL-ENV-۱ از ۰۸:۱۰ EP-REC را متوقف کرده؛ Owner و Next check=۱۱:۳۰؛ Fallback محدود شبکه را نمی‌سنجد.
باگ Critical پیدا کردم.	Observation D-۱۷ مسیر Retry را نقض می‌کند؛ Triage بعد از Daily؛ تا آن زمان Goal=AT_RISK و P2 فعال می‌ماند.
مانعی ندارم.	P3 مانع رسمی ندارد، اما Evidence keyboard هنوز integrated نیست؛ امروز Pair پیش از شروع کار تازه.

Metric را برای تصمیم استفاده کنید، نه نمایش QA

• تعداد Test Case اجراشده بدون Population/Risk/Evidence، Goal progress نیست.
• Pass rate بدون Build/Unknown/Blocked/Stale می‌تواند سبز کاذب باشد.
• Coverage percentage بدون Coverage item و Registry تعریف‌شده بی‌معناست.
• Defect count بدون Severity/State/Population/age اثر را نشان نمی‌دهد.
• Automation count ارزش یا Stability را ثابت نمی‌کند.
• WIP/Age بدون Workflow policy مقایسه‌پذیر نیست.

Daily Scrum نمایشگاه دستاورد QA نیست. تنها Metricی را بیاورید که Conversation و Adaptation همان روز را بهتر می‌کند؛ جزئیات Status را در View مناسب نگه دارید.

DoD را پلیس‌بازی نکنید؛ Gap را مرئی کنید

متخصص تست نباید منتظر بماند تا بگوید «Unit test نداری، Done نیستی». DoD تعهد مشترک Developers است. Gap را با Item/criterion/evidence بیان و Plan را Adapt کنید: چه کار، Pair یا Dependency لازم است تا Increment به DoD برسد؟ اگر DoD نامناسب است، تغییر آن Conversation جدا و Governance خود را دارد.

آزمایش تکرارپذیر: چهار نفر، سه سؤال، PASS

Fixture کاملاً ساختگی SYN-DAILY-SCRUM-EVIDENCE-FLOW-01 چهار گزارش فردی دارد و هر چهار نفر فیلدهای yesterday/today/blocker را پر کرده‌اند؛ کنترل سطحی `PASS` می‌دهد. ممیزی Contract سپس Goal، DoD، Sprint Backlog، Cutoff، Flow policy، آیتم‌ها، Build، Evidence، Age، Blocker، تغییر و Adaptation را بررسی می‌کند.

Contract و Draft ساختگی آزمایش

بعد	Contract	Draft
Goal	SG-17	SG-16
DoD	DOD-v4	DOD-v3
Backlog	SB-SNAP-17-D4	SB-SNAP-17-D2
Cutoff	23 Apr 06:00Z	22 Apr 06:00Z
Flow policy	FLOW-v2	FLOW-v1
Items	P1/P2/P3	P1/P2/P2/P99
Build	B17	P1 Done روی B16
Goal claim	Evidence + Unknown	ON_TRACK بدون هردو
Outcome	Adaptation + Follow-up	هردو عملاً خالی

خروجی واقعی اجرای Fixture

fixture: SYN-DAILY-SCRUM-EVIDENCE-FLOW-01
superficial: PASS | answered=4/4

auditedDraft: HOLD | started=3
findings (27):
1 wrong-sprint-goal:SG-16->SG-17
2 stale-dod:DOD-v3->DOD-v4
3 stale-sprint-backlog:SB-SNAP-17-D2->SB-SNAP-17-D4
4 wrong-facts-cutoff:2026-04-22T06:00Z->2026-04-23T06:00Z
5 stale-flow-policy:FLOW-v1->FLOW-v2
6 missing-goal-contribution:P1
7 foreign-build-done:P1:B16->B17
8 missing-accepted-evidence:P1:EP-FUNCTIONAL
9 missing-work-item-age:P1
10 missing-next-evidence-step:P1
11 missing-accepted-evidence:P2:EP-RECONCILIATION
12 blocker-missing-owner:P2:BL-ENV-1
13 blocker-missing-next-check:P2:BL-ENV-1
14 missing-next-evidence-step:P2
15 duplicate-item:P2
16 missing-accepted-evidence:P2:EP-IDEMPOTENCY
17 missing-accepted-evidence:P2:EP-RECONCILIATION
18 missing-next-evidence-step:P2
19 unknown-item:P99
20 missing-goal-contribution:P99
21 missing-work-item-age:P99
22 missing-next-evidence-step:P99
23 goal-progress-claim-without-evidence
24 goal-progress-unknowns-omitted
25 changes-since-last-omitted
26 no-actionable-plan-adaptation
27 follow-up-missing-owner-or-due

corrected: READY_FOR_DAILY_INSPECTION_REVIEW
started=2 | findings=0

نسخهٔ اصلاحی و مرز نتیجه

نسخهٔ اصلاحی SG-۱۷/DOD-v4/SB-D4/Cutoff جاری/FLOW-v2 را قفل کرد؛ P1/P2/P3 را با Contribution، B17، Evidence، Age و Next step ثبت کرد؛ BL-ENV-۱ Owner/Next check گرفت؛ Goal به `AT_RISK` با Evidence/Unknown تبدیل شد؛ و Adaptation «شروع‌نکردن P4، Swarm روی مانع/P2 و Pair برای P3» WIP شروع‌شده را از ۳ به ۲ کاهش داد. نتیجه فقط `READY_FOR_DAILY_INSPECTION_REVIEW` است.

• همهٔ Goal/PBI/Build/Evidence/روز/نقش/Policy/Metricها ساختگی‌اند.
• Fixture حقیقت یا کفایت Evidence، درستی Goal/DoD و کیفیت Product را نمی‌سنجد.
• کاهش WIP از ۳ به ۲ Threshold جهانی یا اثبات بهبود Flow نیست.
• چهار گزارش فردی یا ۲۷ Finding معیار عملکرد تیم/فرد نیستند.
• خروجی Forecast، Sprint success، Risk acceptance یا Release decision نیست.

سناریوی ایرانی کاملاً ساختگی: Daily Checkout آفلاین

یک تیم خیالی روی Checkout در Lab قطع از شبکه کار می‌کند. Goal ساختگی SG-۱۷ مسیر Checkout قابل استفاده با Retry/Reconciliation جعلی است. اجزا Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger آزمایشی، Reconciliation و Notification fake هستند. هیچ بانک، PSP، مشتری، پول، تراکنش یا Production واقعی وجود ندارد.

Item	State/Age	Evidence	Daily Adaptation
P1 baseline	Done / 2d	EP-FUNCTIONAL B17	Integration check با DoD
P2 retry	Verifying / 4d	IDEMP accepted؛ REC blocked	Swarm روی BL-ENV-۱
P3 interaction	Building / 1d	A11Y candidate	Pair برای keyboard integration
P4 diagnostics	Not started	ندارد	شروع نشود تا WIP آزاد شود

هویت، مبلغ، Unicode و زمان در Daily Lab

• Tenant، Order، Attempt، Callback event، Ledger entry، Run، Build و Evidence ID مستقل‌اند.
• مبلغ canonical فقط IRR ساختگی است؛ تومان فقط View برچسب‌دار است.
• اعداد فارسی «۱۲۵۰۰۰»، عربی «۱۲۵۰۰۰» و لاتین «۱۲۵۰۰۰» دادهٔ synthetic هستند.
• Instantها UTC/ISO ۸۶۰۱، View با Asia/Tehran و جلالی فقط Presentation است.
• Timeout-before/after-fake-commit، retry، duplicate، late و reorder جدا هستند.
• نام، موبایل، ایمیل، IP، حساب، کارت، PAN، CVV2، OTP، Cookie، Token، Secret، Log و Screenshot واقعی ممنوع‌اند.

این Lab هیچ توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا تحریمی دربارهٔ ایران نیست و هیچ رفتار PSP یا تیم واقعی را شبیه‌سازی معتبر نمی‌کند.

نمونهٔ Daily Brief شواهدمحور

Sprint/Goal: SYN-SP-17 / SG-17
Facts-as-of: 2026-04-23T06:00Z | Build: B17 | DoD: v4

تغییر از دیروز:
- P1 EP-FUNCTIONAL پذیرفته شد.
- P2 EP-RECONCILIATION با BL-ENV-1 مسدود شد.

Goal: AT_RISK
شاهد: EV-P1، EV-P2-IDEM، EV-P3-A11Y
Unknown: زمان بازیابی Environment

Flow: سه started بود؛ Policy محلی max=3، اما P2 age=4d و blocked.
Adapt امروز:
1) P4 شروع نشود.
2) دو نفر روی BL-ENV-1 و P2 evidence swarm کنند.
3) P3 با Pair به integrated keyboard evidence برسد.

Follow-up: Env owner تا 11:30 Asia/Tehran؛ نتیجه در BL-ENV-1.
بازرسی بعدی: با تغییر مانع یا Daily بعدی.

Remote و Async Daily Scrum

Scrum Guide زمان/مکان ثابت را برای کاهش پیچیدگی پیشنهاد می‌کند، اما ابزار یا «سرپا بودن» را الزام نمی‌کند. تیم توزیع‌شده می‌تواند بخش‌هایی را async آماده کند، ولی صرف پرکردن Bot form ممکن است Conversation و Adaptation مشترک را حذف کند.

• Board snapshot، Cutoff و Timezone مشترک باشد؛
• Update async به Item/Goal/Evidence ID وصل شود؛
• Overlap کوتاه برای تصمیم/Adaptation حفظ شود یا تصمیم پروتکل روشن داشته باشد؛
• افراد کم‌پهنای‌باند و Screen reader بتوانند مشارکت کنند؛
• Recording پیش‌فرض نباشد؛ access/consent/retention تعیین شود؛
• Bot پاسخ‌ها را Summary کند، نه اینکه Plan را خودکار تغییر دهد؛
• نتیجه در Sprint Backlog canonical ثبت شود.

امنیت و حریم خصوصی در Daily Scrum

ریسک	در رویداد	در Follow-up
Secret/Token	فقط Finding/ID sanitized	مخزن محدود و redacted
PII/Test data	بدون payload واقعی	synthetic/minimized evidence
Security defect	اثر و مسیر need-to-know	restricted triage
Incident detail	Plan impact و owner	incident channel
Recording/transcript	policy/consent	retention/deletion
External observer	least privilege	scoped summary
AI bot	approved data route	prompt/output provenance

هوش مصنوعی و Bot در Daily Scrum

کار	استفادهٔ محدود	Gate
جمع‌آوری Update	پیش‌ورودی async با IDها	Cutoff/source validation
تلخیص تغییرات	Draft change list	مقایسه با Board/Evidence
پرچم‌گذاری aging	Rule محلی	Context و false signal
کشف Dependency	Candidate relation	Owner/condition confirmation
پیشنهاد Adaptation	گزینه‌ها	Developers تصمیم می‌گیرند
صورت‌جلسه	Draft action/follow-up	Canonical update انسانی

مدل ممکن است Done، Severity، Owner یا علت بسازد، اختلاف را حذف یا Plan را به Status فردی تبدیل کند. Model/version، Prompt، Source snapshot، خروجی خام و اصلاح انسانی را ثبت کنید. AI جای empiricism، Conversation یا self-management نیست.

نقش‌ها و حق تصمیم

Accountability/capability	در Daily	مرز
Developers	بازرسی Goal و Adapt Sprint Backlog	How را به مدیر واگذار نمی‌کنند
Testing capability	Evidence gap/Risk/Flow/Testability	قهرمان یا Gate کیفیت نیست
Product Owner	در صورت کار فعال به‌عنوان Developer؛ برای Scope conversation در دسترس	Status receiver اجباری نیست
Scrum Master	اثربخشی Scrum و رفع impediment را enable می‌کند	مالک جلسه/Task assignment نیست
Manager/stakeholder	خارج از Purpose؛ نیاز Status مسیر دیگر	ارزیابی فرد از روی Daily
External specialist	Follow-up/Advice در صورت نیاز	تجویز Plan

کیفیت مسئولیت مشترک است، اما حق تصمیم و تخصص باید روشن باشد. راهنمای رهبری تضمین کیفیت این مرز را باز می‌کند و راهنمای ارتباط تستر و توسعه‌دهنده برای Follow-upهای فنی مرتبط است.

Metricهای سلامت Daily و Countermetricها

Metric	تعریف محدود	Countermetric
Actionable adaptations	تغییرهای Plan با evidence/owner	تغییر بی‌دلیل/نوسان
Follow-up closure	Follow-upهای بسته با خروجی	premature closure
Blocked age	زمان Blocker باز در Window	reopen/fallback harm
WIP	Started-not-finished طبق Policy	item size/type
Work item age	Age آیتم‌های فعال	state/distance to finish
Evidence latency	از change تا accepted evidence	Evidence depth/validity
Goal-claim correction	تصحیح ON_TRACK/AT_RISK	under-reporting
Daily duration	زمان رویداد	quality of adaptation
Speaking distribution	توزیع مشارکت	نیاز واقعی/context
Plan freshness	Backlog update after decision	churn

۱۵ دقیقه Timebox است، نه Target عملکرد. «هر نفر ۶۰–۹۰ ثانیه» قانون Scrum نیست. تیم ممکن است در برخی روزها هیچ Adaptation لازم نداشته باشد؛ صفر تغییر به‌تنهایی شکست نیست، مشروط به بازرسی واقعی و Plan قابل اقدام.

ضدالگوهای Daily Scrum برای تسترها

• نامیدن Daily Scrum به‌عنوان stand-up اجباری و سرپا؛
• سه سؤال اجباری به نام Scrum؛
• گزارش نوبتی به Scrum Master/PO/Manager؛
• حضور مطلق همهٔ QAها و ذی‌نفعان؛
• استفاده برای دیده‌شدن ارزش فرد/واحد QA؛
• تفاوت‌سازی گزارش Tester و Developer بر اساس سیلو؛
• تستر به‌عنوان نمایندهٔ انحصاری کاربر/کیفیت؛
• خواندن Ticketها بدون Goal/Build/Evidence؛
• Done روی Build قدیمی؛
• Pass rate/Coverage/Defect count بدون قرارداد؛
• Regression گسترده از روی هر تغییر بدون Impact analysis؛
• DoD policing به‌جای Plan adaptation؛
• حل Root cause و Triage کامل در ۱۵ دقیقه؛
• «بعداً صحبت می‌کنیم» بدون Owner/Due؛
• Blocker مبهم «محیط خراب است»؛
• شروع کار تازه با WIP aging/blocked؛
• Swarm کردن همه روی همه‌چیز؛
• Threshold جهانی Age/WIP؛
• مقایسهٔ Flow تیم‌ها؛
• Bot form به‌جای Conversation؛
• AI-generated cause/owner/adaptation؛
• کپی PII/Secret/Log در کانال عمومی؛
• ارزیابی عملکرد فرد از روی Daily؛
• برنامهٔ تغییرناپذیر و بدون update Sprint Backlog؛
• ادعای Sprint success/quality/release از Daily.

Pilot سی‌روزه برای Daily Evidence Flow

بازه	کار	خروجی
روز ۱–۵	مشاهدهٔ Daily فعلی و ثبت Goal/Adaptation/Follow-up بدون قضاوت	Baseline
روز ۶–۱۰	تعریف Item/Evidence/Blocker/Flow snapshots	Contract v0.1
روز ۱۱–۱۵	Walk-the-goal آزمایشی و Fixture synthetic	Gap/false-signal log
روز ۱۶–۲۰	Shadow استفاده از Age/WIP با Policy محلی	Decision examples
روز ۲۱–۲۴	تمرین stale Build، blocker و no-follow-up	Recovery evidence
روز ۲۵–۲۷	Remote/accessibility/privacy/AI bot review	Approved route
روز ۲۸–۲۹	Metric+Countermetric و مصاحبه با Developers	Trade-off report
روز ۳۰	Adopt/Adapt/Stop و rollback	Decision record

چک‌لیست قبل و بعد از Daily Scrum

• Sprint Goal ID و متن فعلی دیده می‌شود.
• Sprint Backlog snapshot و Facts-as-of معلوم است.
• DoD و Workflow policy نسخه‌دارند.
• Board با واقعیت Source همگام است.
• هر آیتم Contribution به Goal دارد.
• آیتم تکراری/ناشناخته علامت می‌خورد.
• Work state از Evidence state جداست.
• Done به Build/Data/DoD/Evidence وصل است.
• تغییر از بازرسی قبل مشخص است.
• Risk/Unknown تازه ثبت شده است.
• WIP/Age فقط با تعریف محلی خوانده می‌شود.
• Queue/wait/blocked از active work جداست.
• Blocker، blocked evidence و اثر روشن دارد.
• Owner/Next check/Follow-up URI مشخص است.
• Next evidence step برای کار فعال وجود دارد.
• شروع کار تازه در برابر Finish/Swarm سنجیده شده است.
• Pair/Swarm سؤال و Timebox دارد.
• Goal progress claim Evidence و Unknown دارد.
• Adaptation انتخاب‌شده ثبت شده است.
• کار متوقف/شروع‌نشده صریح است.
• Expected next evidence و Inspect-at معلوم‌اند.
• Follow-up owner/due/output دارد.
• Sprint Backlog پس از تصمیم به‌روز شده است.
• Status بیرونی از مسیر جدا ارسال می‌شود.
• Triage/Root cause به Follow-up منتقل می‌شود.
• هیچ PII/Secret/Log غیرمجاز پخش نمی‌شود.
• Bot/AI provenance و human gate دارد.
• Metricها Countermetric و Context دارند.
• رویداد برای ارزیابی فرد استفاده نمی‌شود.
• نتیجه ادعای Quality/Release/Sprint success نمی‌کند.

مسیر مطالعهٔ مرتبط

• نقش تستر در Sprint Planning: Goal/Risk/Evidence/How آغاز Sprint؛
• گزارش پیشرفت و Blocker Packet: Update رسمی و Forecast؛
• چرخه اجرای تست: Attempt/Outcome/Evidence؛
• تست مبتنی بر ریسک: Risk model و تعهد شاهد؛
• مدیریت نقص: Triage و Closure بیرون Timebox؛
• مستندات تست زنده: Freshness و Drift؛
• رهبری تضمین کیفیت: Whole-team ownership و Authority؛
• ارتباط تستر و توسعه‌دهنده: Follow-up فنی.

سؤالات متداول درباره تستر در Daily Scrum

۱. تستر در Daily Scrum چه بگوید؟

به‌جای فهرست فعالیت شخصی، تغییر مرتبط با Sprint Goal را بیان کند: چه Evidence تازه‌ای روی کدام Build پذیرفته یا رد شد؟ چه Gap/Risk/Blocker/Unknownی Flow را متاثر می‌کند؟ پیشنهاد Adaptation امروز چیست و Next evidence step کدام است؟ جزئیات تشخیصی را به Follow-up زمان‌دار منتقل کند.

۲. آیا سه سؤال دیروز، امروز و مانع در Scrum اجباری است؟

خیر. نسخهٔ ۲۰۲۰ Scrum Guide آن ساختار را الزام نمی‌کند. Developers می‌توانند هر ساختار و تکنیکی انتخاب کنند، به شرط اینکه پیشرفت به Sprint Goal را بازرسی و یک برنامهٔ عملی برای روز بعد بسازند. سه سؤال می‌تواند ابزار اختیاری باشد، اما کامل‌بودن پاسخ‌ها موفقیت رویداد را ثابت نمی‌کند.

۳. آیا Daily Scrum جلسه گزارش وضعیت به Scrum Master یا مدیر است؟

خیر. Daily Scrum رویداد Developers برای self-management و Adaptation است. Scrum Master به اثربخشی Scrum کمک می‌کند، اما گزارش جمع نمی‌کند یا Task تخصیص نمی‌دهد. مدیر/ذی‌نفع اگر Status نیاز دارد، باید View و cadence مناسب دیگری داشته باشد تا Daily به Status theatre تبدیل نشود.

۴. آیا باید باگ و مانع را در همان ۱۵ دقیقه حل کنیم؟

نه. اثر آن بر Goal و Plan را کوتاه مشخص و Adaptation فوری را انتخاب کنید؛ سپس Triage، Root cause یا حل فنی را با افراد لازم در Follow-up دارای Owner، سؤال، Timebox، Due و محل ثبت نتیجه انجام دهید. اگر Incident/خطر فوری است، مسیر تخصصی می‌تواند حتی پیش از Daily فعال شود.

۵. آیا WIP و Work Item Age در Daily Scrum اجباری‌اند؟

خیر. Scrum آن‌ها را الزام نمی‌کند؛ Kanban می‌تواند مکمل اختیاری برای Flow باشد. Metric فقط با Definition of Workflow، Start/Finish، نوع آیتم، Window و Policy محلی معنا دارد. از Threshold جهانی، مقایسهٔ تیم‌ها یا ارزیابی فرد پرهیز کنید و عدد را برای Conversation و تصمیم همان Context به‌کار ببرید.

جمع‌بندی: Daily را از گزارش به Adaptation برگردانید

مشارکت حرفه‌ای قابلیت تست در Daily Scrum به معنی حرف‌زدن بیشتر، دفاع از QA یا اعلام تعداد باگ نیست. Goal و Baseline تازه را ببینید؛ Work و Evidence flow را کنار هم بازرسی کنید؛ Done را به Build/DoD وصل کنید؛ Aging، Risk، Unknown و Blocker را دقیق کنید؛ و سپس تصمیم بگیرید امروز چه چیزی Finish، متوقف، Pair، Swarm یا Re-sequence شود. نتیجه باید در Sprint Backlog و Follow-upهای قابل‌پیگیری بنشیند. این حلقه Plan را با واقعیت سازگار می‌کند—بدون تضمین کیفیت، Sprint success یا Release.