اگر تیم در پایان Sprint Planning فقط یک فهرست PBI و جمع Story Point داشته باشد، هنوز معلوم نیست چگونه یک Increment مطابق Definition of Done میسازد. کار ساخت، آزمون، داده، محیط، مشاهدهپذیری، یکپارچهسازی و شواهد ممکن است در برآورد پنهان مانده باشد؛ یک وابستگی بیمالک میتواند مسیر را ببندد؛ و آیتمهای انتخابی شاید حتی به Sprint Goal مشترک کمک نکنند. مشارکت قابلیت تست در برنامهریزی باید این نادیدهها را به ورودی، تعهد شواهد، کار و Trigger سازگاری قابل مشاهده تبدیل کند.
این راهنما «تستر بهعنوان دروازهبان» یا جلسهٔ جداگانهٔ QA پیشنهاد نمیکند. در Scrum، کل Scrum Team برای ساخت Increment ارزشمند و مفید پاسخگوست و Developers برنامهٔ Sprint Backlog را میسازند. فردی با قابلیت Testing با پرسش، مدل، مثال و شواهد به Why/What/How کمک میکند؛ همانطور که قابلیتهای Product، Development، Operations، Accessibility یا Security کمک میکنند. خروجی، یک Forecast تیمی و برنامهٔ قابل سازگاری است، نه وعدهٔ قطعی یا تأییدیهٔ تستر.
پاسخ کوتاه: مشارکت کیفیت در Sprint Planning چه میسازد؟
- Why: Sprint Goal قابل فهم و محدود، همراه با فرضها و سیگنال نتیجه؛
- What: آیتمهای انتخابی که Contribution آنها به Goal و Eligibility آنها روشن است؛
- How: برنامهٔ ساخت، Verification، Integration، Data، Environment، Evidence و Recovery؛
- Risk: ریسکهای نامدار و Evidence obligationهای متناسب؛
- Capacity: کل کار لازم برای Done، نه فقط Coding یا اجرای Test؛
- Dependency: شرط، مالک پاسخ، زمان نیاز و گزینهٔ جایگزین؛
- Forecast: گزارهٔ شرطی با Unknown، فرض و Trigger بازبرنامهریزی؛
- Inspection: اولین نقاط یادگیری و شواهدی که برنامه را در طول Sprint قابل تطبیق میکند.
Sprint Planning در Scrum رسمی چه میگوید؟
| موضوع رسمی | پرسش | خروجی |
|---|---|---|
| Why | چرا این Sprint ارزشمند است؟ | Sprint Goal |
| What | چه چیزی میتواند در Sprint Done شود؟ | PBIهای انتخابی |
| How | کار انتخابی چگونه Done میشود؟ | برنامهٔ قابل اقدام برای Developers |
| ترکیب | Why + What + How چیست؟ | Sprint Backlog |
راهنمای رسمی Scrum ۲۰۲۰ میگوید Planning با همکاری کل Scrum Team انجام میشود؛ Product Owner آمادگی بحث دربارهٔ PBIهای مهم و ارتباط آنها با Product Goal را فراهم میکند، Developers آیتمها را انتخاب و برنامهٔ انجام را میسازند، و افراد دیگری میتوانند برای مشورت دعوت شوند. راهنما نقش مستقل QA/Tester، User Story، Story Point، Planning Poker، Definition of Ready یا Three Amigos را الزام نمیکند. منبع: Scrum Guide 2020.
مرز مالکیت: Planning با چه فعالیتهایی فرق دارد؟
| فعالیت | پرسش غالب | مرز |
|---|---|---|
| Product Backlog refinement | PBIها چگونه شفافتر و کوچکتر شوند؟ | فعالیت مستمر است؛ Planning میتواند refinement محدود داشته باشد. |
| Sprint Planning | Why/What/How این Sprint چیست؟ | Forecast و Sprint Backlog آغازین را میسازد. |
| Test planning | Risk/Evidence/روش/منابع تست چگونه کنترل شوند؟ | ممکن است فراتر از یک Sprint باشد و ورودی Planning شود. |
| Release planning | مسیر چند Sprint/Release و Forecast چیست؟ | رویداد رسمی Scrum نیست. |
| Daily Scrum | پیشرفت به Goal چگونه بازرسی و برنامه تطبیق شود؟ | Planning یکباره را زنده نگه میدارد. |
| Sprint Review | Outcome و محیط چه Adaptation آیندهای میطلبد؟ | Gate انتشار یا جلسهٔ Approval نیست. |
اگر ابهامهای بنیادین برای اولین بار در Planning کشف میشوند، زمان رویداد صرف کار آمادهسازی دیرهنگام میشود. اما «همهچیز باید پیش از Planning قطعی باشد» نیز با کار پیچیده سازگار نیست. Refinement سطح کافی از شفافیت میسازد و Planning آخرین Conversation و انتخاب Context جاری را انجام میدهد.
نقش تستر در Scrum: قابلیت، نه Accountability چهارم
| مفهوم | تعبیر دقیق | تعبیر نادرست |
|---|---|---|
| Developers | افرادی که هر جنبهٔ Increment قابل استفاده را میسازند | فقط برنامهنویسان |
| Testing capability | توان تحلیل Risk، Oracle، Evidence و Testability | واحد تأیید نهایی |
| Whole team | کیفیت در کار مشترک و DoD مرئی است | هیچ تخصص/استقلالی لازم نیست |
| Self-management | تیم دربارهٔ چهکسی/چهوقت/چگونه تصمیم میگیرد | نبود قرارداد یا پاسخگویی |
| Advice | متخصص میتواند برای تصمیم بهتر دعوت شود | انتقال مالکیت برنامه به بیرون تیم |
اگر فردی با عنوان Tester عضو Scrum Team و در ساخت Increment مشارکت دارد، در واژگان Scrum در مجموعهٔ Developers قرار میگیرد. اگر بیرون تیم مشاور است، Advice میدهد اما Sprint Backlog را برای Developers تجویز نمیکند. ساختار سازمانی شما میتواند عنوانهای تخصصی داشته باشد؛ آنها را با Accountability رسمی Scrum اشتباه نگیرید.
Whole-team quality با حذف استقلال یکی نیست
رویکرد Whole Team یعنی هر فرد دارای مهارت لازم میتواند در کار کیفیت مشارکت کند و کیفیت مسئولیت مشترک است. در Contextهای خاص، سطحی از استقلال آزمون نیز ارزش یا الزام دارد. Sprint Planning باید کار استقلال، Review بیرونی، Evidence یا Approval لازم را بهعنوان Dependency/Work مرئی کند؛ نه اینکه به نام Agile حذف کند. منبع آموزشی و Context-dependent: ISTQB CTFL v4.0.1.
Planning Input Contract
PlanningInput {
sprint_id, product_goal_ref,
candidate_backlog_snapshot,
current_increment_ref,
definition_of_done_version,
past_performance_window,
upcoming_capacity_profile,
known_risks_and_changes[],
environment_data_tool_constraints[],
dependency_records[],
policy_or_external_obligations[],
unresolved_questions[], facts_as_of
}
Input باید Snapshot و Facts-as-of داشته باشد. «Backlog فعلی»، «DoD جدید» یا «ظرفیت معمول» در زمان بازخوانی قابل تفسیر نیست. ورودی کامل به معنی قطعیت نیست؛ Unknown و Change signal نیز ورودیاند.
Sprint Goal را به فهرست آیتمها تقلیل ندهید
SprintGoalContract {
goal_id, statement, stakeholder_value_or_learning,
contribution_hypothesis,
observable_signals[],
constraints[], non_goals[],
assumptions[], invalidation_conditions[],
owner_context, created_at
}
Sprint Goal باید یک هدف واحد و انعطافپذیر بسازد، نه کپی عنوان چند PBI. قابلیت تست کمک میکند عبارت «بهبود پرداخت» به فرض و سیگنال قابل مشاهده تبدیل شود، اما نباید Goal را به فهرست Test Case یا Threshold اختیاری تبدیل کند. ارزش و Outcome با PASS چند تست یکی نیست.
Contribution هر PBI به Goal را آشکار کنید
| پرسش | پاسخ مفید | نشانهٔ هشدار |
|---|---|---|
| چرا این PBI؟ | کدام فرض/Outcome Goal را جلو میبرد؟ | چون بالای Backlog است |
| اگر حذف شود؟ | چه بخش Goal همچنان ممکن/ناممکن است؟ | هیچ اثر روشنی ندارد |
| کوچکترین Slice؟ | چه Increment قابل استفاده/یادگیری میسازد؟ | لایهٔ فنی بدون Outcome |
| شاهد چیست؟ | چه Observation برای Contribution لازم است؟ | فقط Task completion |
| Non-goal چیست؟ | چه چیزی عمداً این Sprint سنجیده نمیشود؟ | ادعای ضمنی همهچیز |
User Story تاکتیک است، نه Artifact الزامی Scrum
PBI میتواند User Story، فرضیه، نقص، Enabler، Experiment یا شکل دیگری داشته باشد. قالب «As a… I want… so that…» ممکن است Conversation را کمک کند، اما پر کردن سه جای خالی، شفافیت یا ارزش را تضمین نمیکند. روی Actor/Need/Outcome/Constraint/Example/Unknown تمرکز کنید و قالب را با Domain تطبیق دهید.
| لایه | سؤال تستپذیری | خروجی |
|---|---|---|
| Need | چه مسئله/Outcomeای دنبال میشود؟ | Claim محدود |
| Actor/context | برای چه کاربر/سیستم/وضعیتی؟ | Population/context |
| Rule | چه رفتار و مرزی معتبر است؟ | Acceptance condition |
| Example | نمونه/ضدنمونهٔ ملموس چیست؟ | Shared model |
| Unknown | چه چیزی هنوز تصمیم یا آزمایش میخواهد؟ | Question/spike |
| Evidence | از چه Observation میآموزیم؟ | Evidence obligation |
Acceptance Criteria با Definition of Done فرق دارد
| قرارداد | دامنه | پرسش | خطای رایج |
|---|---|---|---|
| Acceptance Criteria | PBI/Feature/context | چه شرطهایی برای پذیرش این رفتار مطرحاند؟ | جایگزین همهٔ Test design |
| Definition of Done | Increment/Product minimum | چه معیارهای کیفیت مشترکی برای Increment لازم است؟ | چکلیست اختیاری هر Story |
| Test condition | Risk/behavior نامدار | چه چیزی باید آزموده شود؟ | همان متن AC |
| Test case/charter | Artifact اجرا/کاوش | چگونه شاهد تولید شود؟ | الزام برای هر AC |
| Release condition | تصمیم انتشار | چه ورودی/Authority لازم است؟ | همان DoD |
Acceptance Criteria را فقط به SMART یا عدد تبدیل نکنید. «کمتر از ۲ ثانیه» بدون Population، workload، percentile، محیط و دلیل کسبوکار، Testable به نظر میرسد اما مبهم است. Rule-oriented، Example-oriented یا مدلهای دیگر را بر اساس مسئله انتخاب کنید.
Question Pack قابلیت تست برای Refinement و Planning
- Subject، actor، state و مرز Scope دقیق چیست؟
- کدام Rule/Source/Oracle مرجع است و نسخهٔ آن چیست؟
- مثال معمول، مرزی، نامعتبر، تکراری، دیررس و همزمان چیست؟
- اثر شکست برای چه کسی و در چه Contextی مهم است؟
- کدام Failure باید مهار، بازیابی یا قابل مشاهده شود؟
- چه داده، محیط، سرویس، زمان یا مجوزی لازم است؟
- کدام Evidence برای تصمیم کافی است و چه چیزی را اثبات نمیکند؟
- چه Dependency خارجی و چه Owner/موعدی دارد؟
- کدام Unknown با Spike/Experiment کمهزینهتر میشود؟
- کدام کار باید در DoD انجام شود، نه بعداً در «فاز QA»؟
برای تحلیل عمیقتر Basis و سؤالهای Context-specific، راهنمای تحلیل نیازمندی برای تستر مرجع خوشه است. Sprint Planning جای تکمیل همهٔ طراحی تست نیست؛ باید کار و Risk لازم را قابل برنامهریزی کند.
Risk-to-Evidence در Planning
SprintRiskEvidence {
risk_id, related_goal_or_pbi,
scenario_and_consequence,
current_uncertainty,
evidence_obligations[],
test_levels_or_activities[],
data_environment_oracle_needs[],
owner, timing, limitations,
trigger_for_adaptation
}
«تست مثبت و منفی» Risk model نیست. برای Retry پرداخت، ممکن است تعهد شاهد Idempotency و Reconciliation لازم باشد؛ برای Interaction، Accessibility و keyboard flow؛ برای Migration، rollback/replay. Planning لازم نیست تمام Caseها را بنویسد، اما باید نوع کار و Dependency تولید Evidence را در Forecast ببیند. برای روش کامل، راهنمای تست مبتنی بر ریسک را ببینید.
Evidence obligation با Test count یکی نیست
| تعهد شاهد | کار احتمالی | Counterclaim |
|---|---|---|
| Functional rule | examples + oracle + execution | همهٔ رفتارها پوشش داده نشده |
| Idempotency | retry/duplicate/failure-point tests | Exactly-once جهانی اثبات نشده |
| Accessibility | semantic/keyboard/assistive checks | انطباق کامل اثبات نشده |
| Performance | workload/environment/percentile run | Production capacity تضمین نشده |
| Recovery | fault + restore + reconciliation | تمام Failure modeها آزموده نشده |
| Observability | signal/action drill | تشخیص همهٔ Incidentها تضمین نشده |
Definition of Done را در برنامه مصرف کنید
DoD باید هنگام انتخاب مقدار کار و طراحی How در نظر گرفته شود. اگر Review، آزمون سطح مشخص، Evidence، Documentation، Security scan یا Integration جزء DoD است، ظرفیت آنها هم بخشی از کار است. انتخاب PBI بر اساس زمان Coding و افزودن Testing در پایان، Forecast را از ابتدا ناقص میکند.
DoDImpact {
dod_version,
criterion_id,
affected_items[],
work_slices[],
capability_or_dependency,
evidence_ref_expected,
earliest_feedback_point,
capacity_effect,
unknowns[]
}
کار تست را به انتهای Sprint هل ندهید
| الگوی ضعیف | پیامد | طرح جایگزین |
|---|---|---|
| همهٔ Coding سپس همهٔ Testing | صف، بازخورد دیر و Scope نامعلوم | Slice کوچک build+verify |
| Automation بعد از Sprint | DoD/Regression debt پنهان | Automation work یا Exception روشن |
| Data در روز آخر | Attempt blocked | Data readiness در ابتدا |
| Integration آخر کار | ریسک رابطهای دیر آشکار | Contract/fake/integration points زود |
| Evidence بعد از اجرا | Outcome غیرقابل بازیابی | Evidence profile پیش از run |
| Bugfix بدون confirmation | Closure ادعایی | fix+confirmation+regression impact |
Vertical slice و نقطهٔ یادگیری
Slice مفید باید یک مسیر قابل مشاهده برای ارزش یا یادگیری بسازد؛ نه صرفاً «Backend task»، «Frontend task» و «QA task». برنامه کنید که چه زمانی اولین داده، اولین قرارداد، اولین مسیر نازک، اولین Failure injection و اولین Evidence قابل بازرسی تولید میشود. Slice فنی گاهی اجتنابناپذیر است، اما Contribution و Integration path آن را نام ببرید.
Data readiness در Sprint Planning
| بعد | پرسش | کار برنامهپذیر |
|---|---|---|
| Identity | Snapshot/fixture/version چیست؟ | manifest و seed |
| State | Precondition و cleanup چگونه ساخته میشود؟ | builder/reset |
| Boundary | مقادیر مرزی/نامعتبر/Unicode چیست؟ | dataset design |
| Privacy | واقعی، masked یا synthetic؟ | approval/generation |
| Availability | چه زمان و کجا قابل استفاده است؟ | dependency/check |
| Isolation | Parallel run چه تداخلی دارد؟ | tenant/key isolation |
| Retention | Evidence/data چه مدت میماند؟ | cleanup policy |
Environment readiness و Service dependency
DependencyRecord {
dependency_id, consumer_work,
required_condition, provider_or_owner,
needed_by, current_state,
evidence_of_readiness,
fallback_or_fake, fidelity_limit,
next_check, escalation_trigger
}
«محیط آماده باشد» Task نیست. شرط قابل مشاهده، Owner، موعد، Evidence readiness و Fallback لازم است. Fake/Stub میتواند بازخورد را جلو بیندازد، اما باید Fidelity limit آن در Claim باقی بماند. Dependency بیرون تیم را با امید یا Story Point پنهان نکنید.
Observability و Testability را به کار قابل تحویل تبدیل کنید
- Correlation/Attempt/Event ID برای ردیابی مسیر؛
- Signal ساختاریافته با redaction و access مناسب؛
- Clock/control point برای late/retry/timeout سناریوها؛
- Dependency seam یا fake مجاز؛
- State query/read model برای Oracle مستقل؛
- Feature flag/rollback/cleanup در Context لازم؛
- Metric/trace برای مشاهدهٔ Outcome، نه Log پرحجم صرف؛
- Failure injection کنترلشده با containment.
«تستپذیری» مجوز افزودن endpoint ناامن یا logging حساس نیست. هر Hook باید Threat، دسترسی، محیط، retention و حذف/خاموشی داشته باشد. کار طراحی Testability بخشی از Product design است و ممکن است همان Sprint یا یک Enabler پیشین باشد.
ظرفیت را با واحد سازگار بخوانید
| کمیت | کاربرد | نباید با چه چیزی مقایسه شود؟ |
|---|---|---|
| Story point/relative size | اندازهٔ نسبی Context تیم | ساعت یا ظرفیت تیم دیگر |
| Team-day/hour | محدودیت زمانی تقریبی | Value یا Complexity مطلق |
| Throughput | تاریخچهٔ آیتم با تعریف ثابت | جمعیت/اندازهٔ تغییرکرده |
| WIP | کار همزمان و Flow | درصد Done |
| Skill/capability availability | گلوگاه قابلیت | Headcount خام |
| Calendar availability | تعطیلی/مرخصی/On-call | زمان تمرکز کامل |
در Fixture این مقاله، مقایسهٔ ۸ Story Point با ظرفیت ۸ بهظاهر PASS میشود؛ اما سپس ۹ team-day کار شناسایی میشود. این دو واحد قابل مقایسه نیستند. Story Point را به ساعت QA تبدیل نکنید و «ظرفیت تستر» را صف جدا از ظرفیت کل تیم نسازید؛ کار لازم برای Done باید در Forecast مشترک دیده شود.
برآورد کل کار، نه فقط اجرای تست
- Basis conversation و model/example design؛
- Test condition/case/charter design به اندازهٔ لازم؛
- Data/fixture/environment/fake preparation؛
- Product code و Testability instrumentation؛
- Unit/component/integration/system/exploratory activities؛
- Automation implementation/maintenance و pipeline؛
- Execution، observation و evidence preservation؛
- Defect investigation، fix، confirmation و regression impact؛
- Review، documentation و DoD obligations؛
- Uncertainty buffer یا Spike با Exit question روشن.
Estimation Forecast است، نه تعهد شخصی
راهنمای Scrum میگوید آگاهی Developers از عملکرد گذشته، ظرفیت پیش رو و DoD به اعتماد بیشتر در Forecast کمک میکند. عدد نمیتواند پیچیدگی را حذف کند. Assumption، Range، Unknown و Trigger ابطال را ثبت کنید و از Best-case بهعنوان Commitment استفاده نکنید.
SprintForecastContext {
method, unit, historical_window,
comparable_conditions,
capacity_profile,
selected_work_snapshot,
assumptions[], unknowns[],
dependency_conditions[],
confidence_rationale,
adaptation_triggers[]
}
Unknown را قبل از انتخاب کار نامگذاری کنید
| Unknown | اثر | پاسخ برنامهپذیر |
|---|---|---|
| Rule/Oracle | Acceptance یا PASS/FAIL مبهم | Domain conversation/spike |
| Technical feasibility | اندازه/Approach نامطمئن | prototype |
| Dependency readiness | Blocked flow | owner/check/fallback |
| Data representativeness | Evidence محدود | dataset investigation |
| Performance envelope | Threshold/Capacity نامعلوم | characterization test |
| Policy/authority | Decision قابل نهاییشدن نیست | decision request |
| Production behavior | Lab inference محدود | safe observability/experiment |
Unknown را صفر، Story Point بیشتر یا «ریسک تست» ننامید. اگر Unknown اثر بزرگ دارد، PBI کوچکتر، Spike، گزینهٔ جایگزین یا Forecast بازتر بسازید. Spike باید سؤال، timebox، خروجی و تصمیم بعدی داشته باشد؛ تولید کد بیهدف نیست.
Three Amigos و Example Mapping: تاکتیکهای اختیاری
Business/Development/Testing perspectives میتوانند در Conversation یا Example workshop مفید باشند، اما «سه نفر ثابت» قانون Scrum نیست. Capability مهمتر از عنوان است و Context ممکن است Operations، Security، Accessibility، Data یا Legal perspective بخواهد. خروجی جلسه باید Rule/Example/Question/Decision به Artifactهای canonical برگردد.
| رکورد | نمونه | مصرف در Planning |
|---|---|---|
| Rule | Callback تکراری اثر تازه نسازد | Risk/Evidence obligation |
| Example | دو delivery با Event ID یکسان | Test/data slice |
| Counterexample | Event ID متفاوت با payload یکسان | مرز dedup |
| Question | Window نگهداری ID چقدر است؟ | Unknown/owner |
| Decision | canonical key=tenant+event | Basis/Oracle version |
Sequence برای بازخورد زود و یکپارچهسازی مداوم
Day 0/1: data + environment readiness check -> thin contract/example path -> component evidence -> fake-backed integration -> real allowed dependency check -> exploratory/risk probe -> fix + confirmation -> integrated evidence against DoD -> usable Increment inspection
این Timeline نسخهٔ اجباری نیست. اصل، کوتاهکردن فاصلهٔ ساخت تا Observation و جلوگیری از Batch بزرگ است. اگر Evidence فقط روز آخر قابل تولید است، Risk آن را صریح کنید و ببینید آیا طراحی/محیط/Scope میتواند تغییر کند.
Defect و کار ناخواسته را چگونه در Forecast ببینیم؟
نمیتوان تعداد نقص آینده را دقیق دانست، اما میتوان تاریخچهٔ Comparable، Risk و Recovery policy را دید. ظرفیت ۱۰۰٪ تقویمی را پر نکنید و سپس Investigation/fix/confirmation را «کار اضافهٔ QA» ننامید. Buffer یک عدد جهانی نیست؛ روش، داده و Countermetric لازم دارد. Defect سخت ممکن است Scope negotiation یا Adaptation بخواهد.
Planning Output Contract
SprintPlanView {
sprint_id, sprint_goal_id,
selected_pbi_snapshot,
contribution_map,
dod_version,
risk_evidence_map,
work_slices[], sequence[],
data_environment_dependencies[],
capacity_method_and_unit,
assumptions[], unknowns[],
forecast_context,
inspection_points[],
adaptation_triggers[],
decision_records[], created_at
}
این View جای Sprint Backlog تیم نیست؛ یک Projection برای بررسی کاملبودن How است. Source canonical میتواند Board/Backlog/Docs/Registry باشد، به شرط حفظ ID و Lineage. برای معماری برنامه تست فراتر از Sprint، راهنمای برنامه تست زنده را ببینید.
Sprint Plan Review Gate چه چیزی را بررسی میکند؟
- Goal ID و Contribution انتخابها روشن است؛
- Backlog/DoD/Capacity snapshot تازهاند؛
- آیتم تکراری یا ناشناخته وجود ندارد؛
- کل کار لازم برای Done، شامل Verification، دیده میشود؛
- Riskهای مهم Evidence obligation دارند؛
- Data/Environment/Oracle/Tool dependencyها Owner و زمان دارند؛
- واحدهای اندازه/ظرفیت ناسازگار مقایسه نشدهاند؛
- Sequence نقاط یادگیری و Integration دارد؛
- Unknown/Assumption/Fallback شفاف است؛
- Forecast شرطی و Trigger Adaptation دارد؛
- هیچ Quality/Release guarantee از برنامه نتیجه نشده است.
Gate بالا یک ابزار خودبازبینی است، نه Approval خارجی. Developers مالک برنامهاند و آن را در طول Sprint بهروزرسانی میکنند. «آماده برای بازبینی برنامه» به معنی Doneشدن قطعی انتخابها نیست.
آزمایش تکرارپذیر: ۸ Story Point در ظرفیت ۸
Fixture کاملاً ساختگی SYN-SPRINT-PLANNING-QUALITY-01 یک برنامه با چهار ردیف و جمع ۸ Story Point میسازد. کنترل سطحی فقط میپرسد آیا مجموع Pointها از «ظرفیت ۸» بیشتر نیست؛ بنابراین `PASS` میدهد. ممیزی Contract سپس هویت، Goal، DoD، Contribution، Evidence، Data، Environment، Dependency، Verification work، واحد ظرفیت، Sequence، Unknown و Forecast را بررسی میکند.
داده و Contract Fixture ساختگی
| بعد | Contract | Draft |
|---|---|---|
| Sprint Goal | SG-17 | SG-16 |
| DoD | DOD-v4 | DOD-v3 |
| Backlog snapshot | PB-SNAP-17 | PB-SNAP-16 |
| Registry | P1..P4 | P1/P2/P2/P99 |
| Risk evidence | Functional/Idempotency/Reconciliation/Accessibility | تقریباً خالی |
| Work | build + verification | فقط build |
| Capacity | team-day | story-point با عدد ۸ |
| Dependency | Owner/condition | DEP-PSP-STUB بیمالک |
| Forecast | range/assumption/trigger | تاریخ قطعی بدون فرض |
خروجی واقعی اجرای Fixture
fixture: SYN-SPRINT-PLANNING-QUALITY-01 superficial: PASS | selectedPoints=8 | capacity=8 auditedDraft: HOLD | plannedEffort=9 findings (28): 1 wrong-sprint-goal:SG-16->SG-17 2 stale-dod:DOD-v3->DOD-v4 3 stale-backlog-snapshot:PB-SNAP-16->PB-SNAP-17 4 missing-goal-contribution:P1 5 missing-evidence-obligation:P1:EP-FUNCTIONAL 6 missing-test-data:P1 7 verification-work-not-planned:P1 8 missing-evidence-obligation:P2:EP-RECONCILIATION 9 missing-environment:P2 10 dependency-missing-owner:P2:DEP-PSP-STUB 11 verification-work-not-planned:P2 12 duplicate-selected-item:P2 13 missing-evidence-obligation:P2:EP-IDEMPOTENCY 14 missing-evidence-obligation:P2:EP-RECONCILIATION 15 missing-environment:P2 16 verification-work-not-planned:P2 17 unknown-selected-item:P99 18 missing-goal-contribution:P99 19 missing-test-data:P99 20 missing-environment:P99 21 verification-work-not-planned:P99 22 capacity-unit-mismatch:story-point->team-day 23 full-work-exceeds-capacity:9->8 24 missing-evidence-sequencing 25 unknowns-not-declared 26 forecast-missing-range 27 forecast-missing-assumptions 28 missing-adaptation-trigger corrected: READY_FOR_SPRINT_PLAN_REVIEW plannedEffort=12 | findings=0
تفسیر و محدودیت آزمایش
نسخهٔ اصلاحی SG-۱۷/DOD-v4/PB-SNAP-۱۷ را قفل کرد، P1/P2/P3 یکتا و Goal contribution را ثبت کرد، تعهدهای Functional/Idempotency/Reconciliation/Accessibility را افزود، Data/Environment/Dependency owner را مشخص و build+verification را با جمع ۱۲ team-day در ظرفیت ۱۲ قرار داد. Sequence شواهد، Unknown، بازهٔ Forecast، فرض و Trigger نیز ثبت شد. نتیجه فقط `READY_FOR_SPRINT_PLAN_REVIEW` است.
- همهٔ Sprint/PBI/Goal/DoD/Point/روز/نقش/Rule و تاریخها ساختگیاند.
- Story Point با team-day تبدیل نشده؛ Draft عمداً واحد ناسازگار دارد.
- Ruleها صحت Product Backlog، Goal، DoD، Risk یا Evidence را اثبات نمیکنند.
- Fixture Velocity، بهرهوری، عملکرد فرد، کیفیت، Value یا احتمال Completion را Benchmark نمیکند.
- خروجی Commitment، Sprint success، Risk acceptance یا Release decision نیست.
سناریوی ایرانی کاملاً ساختگی: Checkout آفلاین
یک تیم خیالی روی Checkout در آزمایشگاه کاملاً قطع از شبکه کار میکند. Sprint Goal ساختگی SG-۱۷ این است: «یادگیری و ارائهٔ یک مسیر Checkout قابل استفاده که Retry و تطبیق اثر جعلی را بدون ثبت دوباره مدیریت کند.» اجزا Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger آزمایشی، Reconciliation و Notification fake هستند. هیچ بانک، PSP، کاربر، پول یا Production واقعی وجود ندارد.
| PBI ساختگی | Contribution | Evidence obligation | Dependency |
|---|---|---|---|
| P1 مسیر پایه | مسیر نازک Goal را قابل مشاهده میکند | EP-FUNCTIONAL | DATA-P1-v2 |
| P2 Retry/Callback | اثر تکراری را در Lab مهار میکند | EP-IDEMPOTENCY + EP-RECONCILIATION | DEP-PSP-STUB |
| P3 Interaction | مسیر keyboard/RTL را قابل استفاده نگه میدارد | EP-ACCESSIBILITY محدود | LAB-UI |
| P4 Observability option | تشخیص Attempt را ممکن میکند | EP-DIAGNOSTIC | redaction policy |
هویت، مبلغ، Unicode و زمان در Planning Lab
- Tenant، Order، Attempt، Callback event، Ledger entry، Reconciliation run، Build و Evidence ID جدا دارند.
- مبلغ canonical فقط IRR ساختگی است؛ نمایش تومان label و Rule تبدیل صریح دارد.
- اعداد فارسی «۱۲۵۰۰۰»، عربی «۱۲۵۰۰۰» و لاتین «۱۲۵۰۰۰» دادهٔ synthetic هستند.
- Instantها UTC/ISO ۸۶۰۱، View با Asia/Tehran و تاریخ جلالی فقط Presentation است.
- Timeout-before و timeout-after-fake-commit، duplicate، retry، late و reorder جدا مدل میشوند.
- نام، موبایل، ایمیل، IP، حساب، کارت، PAN، CVV2، OTP، Cookie، Token، Secret، Log و Screenshot واقعی ممنوعاند.
این Lab توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا تحریمی دربارهٔ ایران نیست. هیچ Threshold، رفتار PSP یا فرایند واقعی را بازنمایی نمیکند.
Planning View نمونه برای Lab
Sprint: SYN-SP-17 | Goal: SG-17 | DoD: DOD-v4 Backlog snapshot: PB-SNAP-17 | Facts-as-of: 2026-04-20T08:00Z انتخاب: P1/P2/P3 Contribution: baseline path + retry/reconciliation + accessible interaction کل کار: ۱۲ team-day شامل build، data، verification و evidence Capacity: ۱۲ team-day در Context همین Fixture Dependency: DEP-PSP-STUB شرط: callback fake با Event ID پایدار تا روز ۲ مالک: role:stub-owner | Fallback: offline replay محدودیت Fallback: network parity سنجیده نمیشود Unknown: latency profile کالیبره نیست Forecast: ۲۲ تا ۲۴ آوریل، مشروط به ACK وابستگی پیش از روز ۲ Adapt: اگر ACK نرسید یا Evidence gap Goal را تهدید کرد، Scope/plan بازبینی شود.
امنیت و حریم خصوصی در Planning
| موضوع | پرسش Planning | کار/کنترل |
|---|---|---|
| Test data | آیا PII واقعی لازم است؟ | synthetic/minimized dataset |
| Logs/evidence | چه payloadی ذخیره میشود؟ | redaction/access/retention |
| Test hooks | در کدام محیط و با چه مجوز؟ | auth/disable/remove |
| External tool | داده به کدام سرویس میرود؟ | approved route |
| Security finding | چه کسی باید بداند؟ | need-to-know record |
| Environment | چقدر با Production مشترک است؟ | isolation/containment |
| Cleanup | Artifact/credential چه وقت حذف میشود؟ | expiry/verification |
Planning نباید Credential، Sample واقعی یا جزئیات آسیبپذیری را در Board عمومی کپی کند. Task و Dependency میتوانند sanitized باشند و Evidence در Repository مجاز قرار گیرد.
Remote/Async Sprint Planning بدون شکستن Conversation
- Snapshot ورودی و Timezone را پیش از رویداد منتشر کنید؛
- Questionها را با Owner و Due ثبت کنید، نه در چند Chat گمشده؛
- مثال/مدل را برای Screen reader و keyboard قابل استفاده کنید؛
- رأی یا Estimate را پیش از Discussion به حقیقت تبدیل نکنید؛
- تصمیمها را به Goal/PBI/DoD/Dependency ID وصل کنید؛
- Offline participant و latency را در Facilitation ببینید؛
- Recording را پیشفرض و بیمحدودیت نکنید؛ رضایت/retention/access لازم است؛
- نتیجه را در Sprint Backlog canonical همگام کنید.
هوش مصنوعی در Refinement و Planning
| کار | استفادهٔ محدود | Gate |
|---|---|---|
| Question generation | Candidate edge/risk questions | Domain/team review |
| Example generation | synthetic examples/counterexamples | Rule/Oracle validation |
| Dependency extraction | Candidate refs from PBI | Owner/condition confirmation |
| Work decomposition | Candidate slices | Developers own plan |
| Estimate summary | record assumptions/disagreement | عدد نسازد/تحمیل نکند |
| Planning recap | Draft Goal/decision/unknowns | canonical IDs and human approval |
مدل ممکن است Requirement، Policy، Threshold، Dependency یا ظرفیت را جعل کند و اختلاف را با خلاصهای روان حذف کند. Model/version، Prompt، Source snapshot، خروجی خام و ویرایش انسانی را در کاربردهای اثرگذار ثبت کنید. PII/Secret را بدون مجوز وارد سرویس بیرونی نکنید و AI را Estimator یا Product Owner/Developer proxy نکنید.
نقشها و حق تصمیم در Planning
| Accountability/capability | کمک در Planning | مرز |
|---|---|---|
| Product Owner | Value، Product Goal، PBI transparency/order | اندازه را برای Developers تعیین نمیکند |
| Developers | انتخاب What، ساخت How و Forecast | DoD/Goal را دور نمیزنند |
| Scrum Master | فهم Scrum و اثربخشی رویداد | Project manager تخصیصدهنده نیست |
| Testing capability | Risk/Example/Oracle/Evidence/Testability | QA approval gate نیست |
| Domain stakeholder | Rule/Outcome/constraint advice | Sprint Backlog را مالک نمیشود |
| Security/ops/accessibility/data | تعهد تخصصی و dependency | همهجا الزامی نیست؛ Context-based |
| Release/risk authority | Policy/decision input در صورت نیاز | Sprint Planning خود Release gate نیست |
برای مرز مالکیت و کیفیت مشترک، راهنمای رهبری تضمین کیفیت را ببینید. برای همکاری روزمره با Product Owner و Developer نیز همکاری تستر و Product Owner و ارتباط تستر و توسعهدهنده مرزهای رفتاری خوشهاند.
Adaptation Triggerها را از ابتدا بنویسید
AdaptationTrigger {
trigger_id, observable_condition,
related_goal_or_work,
evidence_source,
response_options[],
decision_participants,
next_inspection_time,
record_updated
}
- Dependency تا زمان نیاز Acknowledged نشده است؛
- Goal assumption با Evidence رد شده است؛
- DoD obligation یا Evidence gap از ظرفیت عبور میکند؛
- Scope/priority یا Product environment تغییر معنادار دارد؛
- Data/Environment invalid یا unavailable است؛
- Failure با پیامد بالاتر از مدل Risk ظاهر شده است؛
- Work item بزرگتر از Slice/Forecast فرضشده است.
Trigger خودکار به معنی تصمیم خودکار نیست؛ Conversation و Authority Context لازم است. برای بستهٔ گزارش پیشرفت/مانع و Forecast در طول Sprint، راهنمای Update و Blocker Packet را ببینید.
متریکهای سلامت Planning و Countermetricها
| Metric | تعریف محدود | Countermetric |
|---|---|---|
| Goal contribution coverage | انتخابهای با Contribution روشن/کل | کیفیت/واقعیت Contribution |
| Hidden-work discovery | کار DoD/Evidence کشفشده پیش از شروع | over-planning |
| Dependency readiness | Dependencyهای با Owner/condition/evidence | external delay |
| Early evidence time | زمان تا اولین Evidence معتبر | Evidence depth |
| Blocked aging | زمان کار مسدود | premature fallback |
| Scope churn | Delta انتخابها با علت | healthy adaptation |
| Forecast calibration | Outcome داخل range | range width |
| DoD spillover | کار DoD منتقلشده/کل | Scope/value changes |
| Unknown resolution | Unknownهای پاسخگرفته در موعد | forced certainty |
| Planning time | زمان رویداد | decision quality/rework |
Velocity، Story Point یا تعداد Case را KPI فرد/تستر نکنید. افزایش «Accuracy تخمین» ممکن است با بازهٔ بیشازحد پهن یا حذف کار دشوار بازی شود. Metric باید Population، Window، تعریف و Countermetric داشته باشد و برای یادگیری تیم استفاده شود، نه مقایسهٔ تیمها.
ضدالگوهای حضور تستر در Sprint Planning
- ساخت Accountability چهارم «QA» در Scrum؛
- دعوت تستر برای Approve کردن Storyها؛
- دیدن Developers بهعنوان فقط برنامهنویس؛
- کشف همهٔ ابهامها برای اولین بار در Planning؛
- Definition of Ready اجباری به نام Scrum؛
- User Story/Story Point/Three Amigos اجباری به نام Scrum؛
- کپی PBIها بهعنوان Sprint Goal؛
- معیار پذیرش SMART/عددی بدون Context؛
- یکیدانستن AC، DoD، Test Case و Release gate؛
- فقط Happy/Negative/Edge بهعنوان Risk strategy؛
- برآورد Coding و افزودن Testing بعداً؛
- صف QA در روزهای آخر؛
- Story Point جداگانهٔ QA یا تبدیل Point به ساعت؛
- مقایسهٔ عددهای هماندازه با واحد متفاوت؛
- تخمین توسط فردی که کار را انجام نمیدهد و تحمیل به Developers؛
- Dependency بدون Owner/condition/needed-by؛
- Fake بدون Fidelity limitation؛
- Data/Environment «آماده باشد» بدون Evidence؛
- Automation/Observability/cleanup خارج از DoD پنهانی؛
- صفرکردن Unknown یا تبدیل آن به Point بیشتر؛
- تاریخ Forecast قطعی بدون فرض/Range؛
- پرکردن ۱۰۰٪ ظرفیت تقویمی؛
- AI-generated Estimate/Goal بدون Source؛
- کپی PII/Secret در Board؛
- نتیجهگیری موفقیت Sprint/کیفیت/Release از Plan.
Pilot سیروزه برای Planning شواهدمحور
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | مشاهدهٔ یک Planning و استخراج Hidden work/blocked/unknown | Baseline بدون سرزنش |
| روز ۶–۱۰ | تعریف Input/Goal/Contribution/Risk-Evidence contracts | Template v0.1 |
| روز ۱۱–۱۵ | Fixture synthetic و کنترل واحد/duplicate/dependency | Executable checks |
| روز ۱۶–۲۰ | Shadow use روی یک Sprint؛ روش فعلی حفظ شود | Time/noise/gap comparison |
| روز ۲۱–۲۴ | تمرین Dependency fail، stale DoD و Scope change | Adaptation evidence |
| روز ۲۵–۲۷ | بازبینی امنیت، دسترسپذیری و remote flow | Approved collaboration route |
| روز ۲۸–۲۹ | Metric+Countermetric و مصاحبه با تیم | Trade-off report |
| روز ۳۰ | Adopt/Adapt/Stop با rollback | Decision record |
چکلیست نهایی مشارکت قابلیت تست
- Product Goal و Context قابل دسترسی است.
- Backlog snapshot و Facts-as-of ثبت شدهاند.
- DoD نسخهدار و اثر آن بر کار دیده شده است.
- Past performance و upcoming capacity با Context آمدهاند.
- Sprint Goal یک هدف و Non-goal/فرض روشن دارد.
- هر انتخاب Contribution به Goal دارد.
- PBIهای تکراری/ناشناخته حذف شدهاند.
- Acceptance condition از DoD و Release جداست.
- Riskهای مهم Scenario/Consequence دارند.
- Evidence obligationها به Risk/PBI وصلاند.
- Test design detail به اندازهٔ تصمیم Planning است.
- Data ID/state/boundary/privacy/readiness روشن است.
- Environment/fake fidelity و readiness مشخص است.
- Oracle/Source/Rule و نسخه معلوماند.
- Observability/Testability کار و کنترل امنیت دارد.
- Build، verify، integrate، evidence و cleanup دیده شدهاند.
- Work به Sliceهای بازخوردپذیر شکسته شده است.
- اولین نقاط Evidence و Integration مشخصاند.
- Dependency شرط/owner/needed-by/next-check دارد.
- واحد Point/time/throughput/capacity قاطی نشده است.
- کل کار لازم برای Done در Forecast دیده میشود.
- Unknown و Spike question/exit روشناند.
- Forecast Range/assumption/confidence context دارد.
- Adaptation trigger و decision participants معلوماند.
- Developers مالک What/How و plan باقی ماندهاند.
- Testing capability Advice است، نه QA gate.
- AI/Tool provenance و human review دارند.
- Board/record حاوی Secret/PII غیرمجاز نیست.
- Metricها Countermetric و denominator دارند.
- Plan ادعای Completion/Quality/Release قطعی نمیکند.
مسیر مطالعهٔ مرتبط
- تحلیل نیازمندیها: سؤال، Test Basis و Trace؛
- تست مبتنی بر ریسک: Risk model و Evidence؛
- برنامه تست زنده: Planning چندسطحی، Scope و Gate؛
- گزارش پیشرفت و Blocker: Adaptation در طول Sprint؛
- رهبری تضمین کیفیت: Whole-team ownership و Authority؛
- همکاری با Product Owner: Value/Basis conversation؛
- ارتباط تستر و توسعهدهنده: همکاری فنی و بازخورد.
سؤالات متداول درباره نقش تستر در Sprint Planning
۱. آیا حضور تستر در Sprint Planning طبق Scrum اجباری است؟
Scrum نقش مستقل Tester را تعریف نمیکند؛ Sprint Planning با همکاری کل Scrum Team انجام میشود. اگر متخصص تست عضو Scrum Team و در ساخت Increment مشارکت دارد، در واژگان Scrum در Developers قرار میگیرد و مانند دیگران مشارکت میکند. فرد بیرون تیم میتواند برای Advice دعوت شود. شکل دقیق Capabilityها و عنوانها Context سازمان است.
۲. تستر در Sprint Planning چه سؤالهایی بپرسد؟
سؤال را به Goal و تصمیم وصل کند: Rule/Oracle چیست؟ Failure consequence کدام است؟ چه مثال و مرزی مهم است؟ چه Evidence لازم داریم؟ Data/Environment/Dependency چه زمانی و با چه Owner آماده است؟ کدام کار DoD پنهان مانده؟ چه Unknown یا فرضی Forecast را باطل میکند؟ هدف نوشتن همهٔ Test Caseها در جلسه نیست.
۳. آیا تستر باید Story Point یا تخمین جداگانهٔ QA بدهد؟
در Scrum، Developers که کار را انجام میدهند مسئول Sizing و Plan هستند. Capability تست باید کار Data، Environment، Verification، Automation، Evidence و Investigation را مرئی کند تا اندازه/Forecast تیمی آن را شامل شود. Point جداگانهٔ QA صف و handoff میسازد؛ تبدیل Story Point به ساعت نیز بدون قرارداد معتبر نیست.
۴. آیا همهٔ User Storyها باید پیش از Sprint توسط تستر تأیید شوند؟
خیر. User Story و QA approval الزام Scrum نیستند. PBI باید برای انتخاب به اندازهٔ کافی شفاف باشد و تیم در Planning میتواند آن را بیشتر refine کند. ابهام یا Risk اثرگذار باید مرئی و پاسخ داده یا به Unknown/Dependency/Spike تبدیل شود. تستر مشاور و همکار است؛ Product Owner و Developers accountabilityهای خود را حفظ میکنند.
۵. تفاوت Acceptance Criteria، Definition of Done و Test Case چیست؟
Acceptance Criteria شرطهای Context-specific یک PBI را توضیح میدهد؛ Definition of Done معیار کیفیت مشترک Increment است؛ Test Case یا Charter روشی برای تولید شاهد دربارهٔ Test condition است. ممکن است به هم Trace شوند، اما جای هم نیستند. هیچکدام بهتنهایی Release decision یا کیفیت کلی محصول را ثابت نمیکند.
جمعبندی: کیفیت را در How برنامهریزی کنید
مشارکت مؤثر قابلیت تست در Sprint Planning با «چه میشود اگر؟» آغاز میشود، اما با فهرست سناریو تمام نمیشود. Goal و Contribution را روشن کنید؛ DoD را به کار واقعی تبدیل کنید؛ Risk را به Evidence obligation وصل کنید؛ Data، Environment، Oracle، Testability و Dependency را زماندار کنید؛ کل کار build-to-evidence را در ظرفیت ببینید؛ Unknown و Forecast را صادقانه نگه دارید؛ و نقطههای بازرسی و Adaptation را از ابتدا طراحی کنید. نتیجه یک Sprint Backlog شفافتر و قابل تطبیق است—نه تضمین کیفیت، نه وعدهٔ تحویل و نه دروازهٔ QA.
