دو QA برای پنج محصول: از بحران اولویت تا جریان شفاف – راهکار اسکرام

راهنمای عملی برای تسهیل اولویت‌ها، ظرفیت‌سنجی، و ساخت کیفیت درون فرایند (Scrum Guide 2020)

Problem Context — قصه‌ی یک تیم QA «سِرویسی»

یک تیم QA دو نفره داریم که بین ۵ محصول به‌اشتراک گذاشته شده‌اند. هر PO در بورد اسپرینتِ خودش «تسک QA» می‌گذارد و تیم QA موظف است این تسک‌ها را از محصولات مختلف بگیرد و انجام دهد. مشکل‌ها از این‌جا شروع شده‌اند:

• کاهش انگیزه برای اتوماسیون؛ چون QA بیشتر نقش «QCِ انتهایی» دارد تا «ساخت کیفیت».
• ابهام و تعارض در اولویت‌ها؛ چند صف جداگانه برای QA، و برخی تسک‌های واقعاً حیاتی تا یک هفته زمین مانده‌اند و نارضایتی ایجاد شده.
• نیاز به حضور بالادستی؛ یکی از QAها (سینیور) می‌خواهد در برنامه‌ریزی و ریفاینمنت محصولات درگیر شود، سناریوی تست را طراحی کند و زیرساخت اتوماسیون را پیش ببرد؛ اما با «سفارش هفتگی تسک از همه‌ی POها» عملاً در فرایندِ تولیدِ اینکریمنت حضور مؤثر ندارد.

از نگاه اسکرام، این وضعیت پیچیده (Complex) است: چند محصول، ذی‌نفعان متعدد، اولویت‌های متغیر. در چنین فضاهایی نسخه‌ی واحد جواب نمی‌دهد؛ باید با شفافیت، اندازه‌گیری و آزمایش‌های کوچکِ امن برای شکست به مدل پایدار برسیم.

---

چرا این اتفاق می‌افتد؟ (لنز Scrum 2020)

• در اسکرام، منبع واحد کار، Product Backlog مرتب‌شده توسط PO است؛ صف‌های موازیِ «QA-محور» اغلب تعارض می‌سازند.
• کیفیت در Definition of Done نهادینه می‌شود، نه با یک «مرحلهٔ QA انتهایی». تا زمانی که PBI به DoD نرسد، بخشی از اینکریمنت محسوب نمی‌شود.
• تیم‌ها خودمدیر و کراس‌فانکشنال‌اند و مسئول تمام فعالیت‌های محصول‌اند؛ جداسازی وظیفه‌ای/دپارتمانی (مثل «QA مشترک صف‌محور») تمرکز بر «تمام کردن» را سخت می‌کند.

---

راه‌حل پیشنهادی — یک مدل عملیاتی قابل اجرا از اسپرینت بعد

1) نقش «تسهیلگر» را دقیق تعریف کنید (Coach جریان، نه «مالک اولویت»)

تسهیلگر باید به POها کمک کند بک‌لاگ را Ordered نگه دارند، موانع را بردارد، و تیم‌ها را برای خودمدیریتی توانمند کند؛ تصمیم درباره‌ی Ordering متعلق به PO است و باید در شفافیتِ بک‌لاگ دیده شود.
نکتهٔ حرفه‌ای: تسهیلگری، آموزش و کوچینگ قابلیت‌های کلیدی‌اند که باید در تیم رشد کنند؛ الزاماً همه‌چیز کار Scrum Master نیست، اما او «رهبر-خدمتگزار» و نگه‌دارنده‌ی کارایی چارچوب است.

2) یک «ورودی واحد» برای QA بسازید (Kanban روی ورودی، با سیاست‌های شفاف)

وقتی QA مشترک اجتناب‌ناپذیر است، بجای چند صف پراکنده، یک بُرد کانبانِ ورودیِ واحد تعریف کنید که فقط «ترکیبِ صف مشترک» را نشان دهد:

• کلاس‌های سرویس: Standard / Fixed-date / Expedite (استثنایی و کم‌تکرار).
• WIP Limit سخت (مثلاً ۲ آیتم در In-Progress) تا چندکارگی کم شود و «تمام کردن» جای «شروع کردن» را بگیرد.
• Replenishment هفتگی: تسهیلگر + همهٔ POها آیتم‌های Ready را برای هفتهٔ پیش‌ِ رو به یک ترتیب واحد می‌چینند؛ ترتیب هر محصول را همان PO تعیین می‌کند، اما بُرد QA تنها «ترکیب صف» را نشان می‌دهد (نه مالکیت تصمیم).

3) ظرفیت را دو سبد کنید: «بالادست» برای ساخت کیفیت، «پایین‌دست» برای تحویل

در هر اسپرینت، ظرفیت دو نفر QA را شفاف تقسیم کنید:

• Upstream (۳۰–۴۰٪ ثابت): حضورِ هدفمند در ریفاینمنت/پلنینگ محصولات منتخب، طراحی سناریوی تست، هم‌طراحی معیارهای پذیرش، زیرساخت اتوماسیون (CI, AT, Regression Critical).
• Downstream (۶۰–۷۰٪): اجرای تست‌های سیستمی/رگرسیون برای آیتم‌های Ready-for-QA.
  این Time-boxing به QA سینیور اجازه می‌دهد بخشی از فرایند ساخت اینکریمنت باشد، نه صرفاً QC انتهایی.

4) کیفیت را در DoD بکارید (اتوماسیون در خطِ مبنا)

DoD هر محصول را به‌روزرسانی کنید تا سطوح توافق‌شدهٔ اتوماسیون (واحد، ادغام، رگرسیون بحرانی)، Build/Test خودکار و معیارهای پذیرش روشن در آن باشند. بدون تحقق DoD، کار جزء اینکریمنت نیست.
الگوی رشد اتوماسیون: کنترل نسخه → بیلد خودکار → تست خودکار → بسته‌بندی → استقرار خودکار.

5) جلوگیری از «تزریق کار» به وسط اسپرینت

هر کار QA برای یک محصول باید از بک‌لاگ همان محصول انتخاب شود و در هدف اسپرینت آن تیم بازتاب داشته باشد؛ بُرد QA «صف اجرا» است، نه دور زدن برنامهٔ تیم محصول. اسکرام رخدادهای شفاف برای بازبینی/انطباق دارد؛ میان‌بُر زدن، فرصت انطباق را از بین می‌برد.

6) ظرفیت عادلانه بین محصولات (سه الگوی ساده)

یکی را به‌صورت آزمایش ۲–۳ اسپرینتی امتحان کنید و با داده‌ی جریان بازبینی کنید:

1. سهم ثابت (مثلاً A=۳۰٪، B=۲۵٪، …) — پیش‌بینی‌پذیر.
2. سهم پویا بر اساس ورودی Ready (حجم دو هفتهٔ اخیر) — سازگار با تغییر.
3. سهم مبتنی بر موعد/اهداف نزدیک‌تر — تمرکز بر ریسکِ موعد.
   هر سه با اندازه‌گیریِ چرخه‌زمان/جریان معنادار می‌شوند.

7) ریتم‌های سبک اما مؤثر

• Daily Flow Review (۱۰ دقیقه) روی بورد کانبانِ ورودی: آیا WIP شکسته؟ چه چیزی گیر کرده و چه کسی مانع را برمی‌دارد؟ (تسهیلگر نقش کوچ جریان را دارد.)
• Weekly Replenishment با POها (بخش ۲).
• Retro ماهانهٔ مشترک (QA + نماینده‌ی هر محصول) بر محور کیفیت/کارایی؛ تصمیم‌های بهبود را سریع وارد اسپرینت بعد کنید.

---

۴ آزمایش «امن برای شکست» (به‌ترتیب پیشنهادی)

1. WIP=۲ در In-Progress QA و ممنوعیت شروع آیتم جدید تا «Done» شدن یکی از درحال‌کارها. شاخص موفقیت: کاهش Cycle Time و افزایش درصد آیتم‌های Done در نیمهٔ اول اسپرینت.
2. Time-box ۳۰–۴۰٪ Upstream برای ۲ محصول شاخص (چرخشی هر ۴ هفته). شاخص موفقیت: افت باگ‌های برگشتی/ابهام پذیرش.
3. DoD ارتقایافته با حداقل یک لایه تست خودکار در همهٔ محصولات. شاخص موفقیت: رشد عبور تست‌های خودکار در CI و کاهش Defect-Escape.
4. Ordering واحدِ صف QA (به‌جای Priority چندگانه). شاخص موفقیت: حذف «آیتم‌های اولویت‌دار جامانده» و کاهش شکایت POها.

---

سنجه‌هایی که هفتگی پایش کنید

• Cycle Time به تفکیک کلاس سرویس + Service Level Expectation تحقق‌یافته.
• درصد PBIهایی که قبل از نیمهٔ اسپرینت به DoD رسیده‌اند (کاهش ترافیک انتهای اسپرینت).
• درصد عبور تست‌های خودکار در CI و Defect-Escape پس از ریلیز.

---

FAQ کوتاه

آیا تسهیلگر می‌تواند اولویت‌دهی کند؟
نه؛ او شفاف‌سازی و هماهنگ‌سازی می‌کند تا POها Ordering را انجام دهند و تصمیم‌ها در بک‌لاگِ هر محصول قابل مشاهده باشد.

QA مشترک با اسکرام ناسازگار است؟
اسکرام می‌گوید تیم‌ها کراس‌فانکشنال و خودمدیر هستند و کیفیت باید در DoD نهادینه شود. اگر به‌دلایل سازمانی QA مشترک دارید، آن را به‌صورت جریان شفاف با WIP محدود، ریتم‌های بازرسانه، و ظرفیتِ Upstream محفوظ اداره کنید تا ضدالگوها به حداقل برسند.

چطور انگیزهٔ اتوماسیون را بالا ببریم؟
اتوماسیون را به‌جای «بهترین‌داستان اختیاری»، بخشی از DoD و هدف تیم کنید؛ سرمایه‌گذاری امروز، ظرفیت فردا را آزاد می‌کند. الگوی رشد اتوماسیون را در DoD شفاف کنید.

---

جمع‌بندی

برای بیرون آمدن از تله‌ی «QA صف‌محورِ خسته و پراسترس»، سه تغییر کلیدی را هم‌زمان پیاده کنید:

1. Ordering واقعی در Product Backlog توسط POها + ورودی واحدِ QA برای حذف تعارض صف‌ها.
2. تقسیم ظرفیت به Upstream/Downstream تا QA در ساخت کیفیت (نه فقط QC انتهایی) شریک شود و اتوماسیون جلو برود.
3. DoD ارتقایافته با اتوماسیون + WIP محدود برای تمرکز بر «تمام کردن».

نتیجه‌ی عملی این مدل: اولویت‌ها شفاف، انتظارها واقع‌بینانه، چرخه‌زمان کوتاه‌تر، و انگیزه‌ی تیم برای اتوماسیون واقعی‌تر می‌شود—دقیقاً همان چیزی که اسکرام برای محیط‌های پیچیده تجویز می‌کند.

---

منابع اشاره‌شده

• Scrum Guide 2020 (تعاریف نقش‌ها، آرтеفکت‌ها، DoD، بک‌لاگ و رویدادها).
• Mastering Professional Scrum (جریان، محدودکردن WIP، آناتومی اتوماسیون و کیفیت از ابتدا).
• Fixing Your Scrum (الگوهای ضدِ «کار زیاد در جریان»، توصیه‌های عملی WIP و مالکیت تیمیِ اینکریمنت).

---

/c — «بوم اجرای ۲هفته‌ای» برای تیم QA مشترک (همزمان حلِ اولویت، ظرفیت‌سنجی، و حرکت به‌سمت اتوماسیون)

1) هدفِ ۲ هفته‌ی آینده

• Outcome 1: صف‌های پراکنده‌ی QA به یک ورودی واحدِ قابل‌مشاهده تبدیل شود؛ تصمیم‌های ترتیب‌دهی توسط POها قابل‌رهگیری باشند.
• Outcome 2: ظرفیت QA بین بالادست (طراحی تست/اتوماسیون) و پایین‌دست (اجرای تست) به‌صورت شفاف Time-box شود.
• Outcome 3: حداقل یک لایه‌ی تست خودکارِ بحرانی وارد Definition of Done محصولات شود.
• Outcome 4: کاهش چندکارگی با WIP=2 در ستون «In-Progress» و کشاندن آیتم‌ها به «Done» زودتر در اسپرینت.

---

2) آزمایش‌های «امن برای شکست» (تعهدِ تیم برای ۲ هفته)

1. WIP=2 روی برد QA (ستون In-Progress). شاخص موفقیت: کاهش Cycle Time و افزایش درصد آیتم‌های Done در نیمهٔ اول اسپرینت.
2. تقسیم ظرفیت 40/60: ۴۰٪ وقت به بالادست (ریفاینمنت/ATDD/زیرساخت CI)، ۶۰٪ به اجرای تست. شاخص: کاهش برگشت/ابهام پذیرش.
3. DoD ارتقایافته: «Build/Test خودکار حداقل برای سناریوهای بحرانی» به DoD هر محصول اضافه شود؛ بدون تحقق DoD، آیتم جز Increment نیست.
4. Replenishment هفتگیِ واحد: ترکیب صف QA با حضور همه‌ی POها مرتب (Ordered) شود؛ تصمیم Ordering متعلق به PO همان محصول است، نه تسهیلگر.

---

3) نقش‌ها و مسئولیت‌ها

• POهای محصولات: مالک Ordering بک‌لاگِ محصول و تصمیم شفاف دربارهٔ ترتیب آیتم‌ها.
• QA (۲ نفر): پایبندی به DoD، اجرای WIP، به‌روزرسانی Sprint Backlog/برد جریان و کار روی اتوماسیون طبق Time-box.
• تسهیلگر (SM/Coach جریان): تضمین رویدادهای اسکرام و کیفیت تسهیل، حذف موانع، مربی‌گری خودمدیریتی تیم و همکاری با POها برای شفافیت Ordering.

---

4) برد «ورودی واحد QA» + سیاست‌ها

• ستون‌ها: Ready → Selected (۱ هفته) → In-Progress (WIP=2) → Verify/PO Sync → Done. (تمرکز بر کشیدن به Done، نه شروع‌ جدید)
• کلاس‌های سرویس: Standard / Fixed-date / Expedite (استثنایی کم‌تکرار). (برای مدیریت توافق انتظارات)
• Definition of Ready برای QA: معیار پذیرش شفاف، داده/محیط آماده، Build قابل‌اجرا. (بازبینی در Replenishment)
• سیاست جریان: شروع آیتم جدید فقط وقتی ممکن است که WIP نشکند؛ هر نفر در دسترس، اول به آزاد کردن آیتم‌های درحال‌کار کمک کند. (قانون تمرکز بر «تمام کردن»)

---

5) برنامهٔ ۲ هفته‌ای (تقویم عملیاتی)

هفتهٔ ۱

• روز 1 – Replenishment واحد (۶۰‌دقیقه): تسهیلگر + همهٔ POها
  • ورودی‌های Ready را مرور و به ترتیب واحد برای هفته بچینید (بر اساس Ordering هر PO).
  • تعیین حجم قابل‌قبول برای Selected (ظرفیت هفته + کلاس سرویس).
• روز 1 – برنامه‌ریزی ظرفیت QA (۳۰‌دقیقه):
  • تعیین ۴۰٪ بالادست (دو محصول هدف) + ۶۰٪ پایین‌دست؛ ثبت Time-box در Sprint Backlog.
• روز 1 – به‌روزرسانی DoD (۴۵‌دقیقه با هر تیم محصول): افزودن بند «Build/Test خودکار بحرانی» به DoD.
• روزهای 2 تا 5 – اجرای کار + Daily Flow Review (۱۰ دقیقه):
  • بررسی شکستن WIP، انسدادها، و هماهنگی Syncهای لازم با PO همان محصول.
  • بالادست: حضور QA سینیور در ریفاینمنت/پلنینگ ۲ محصول منتخب، طراحی سناریوهای ATDD و ایجاد تست‌های خودکار اولیه در CI.
• روز 4 – Sync کیفیت (۳۰‌دقیقه): مرور پوشش تست خودکار و مشکلات محیط/داده.

هفتهٔ ۲

• روز 6 – Replenishment کوتاه (۳۰‌دقیقه): به‌روزرسانی Selected بر اساس واقعیت جریان و تاریخ‌های Fixed-date.
• روزهای 6 تا 9 – ادامهٔ اجرا + Daily Flow Review (۱۰ دقیقه): بازبینی Sprint Backlog، کشیدن آیتم‌ها به Done زودتر؛ پرهیز از تزریق کار خارج از بک‌لاگ محصول.
• روز 9 – آمادگی Review (۴۵‌دقیقه): تضمین شواهد DoD و نتایج تست‌های خودکار برای آیتم‌های هر محصول.
• روز 10 – Sprint Review/Retrospective مشارکتی (دو بخش):
  • Review: حضور POها و ذی‌نفعان؛ بازخورد روی اینکریمنت‌ها و دادهٔ جریان. (نه داوری/قاضی‌گری؛ گفت‌وگوی شفاف مداوم)
  • Retrospective (تمرکز بر کیفیت/اثربخشی): شناسایی ۱–۲ تغییر اثرگذار برای اسپرینت بعد و افزودن به Sprint Backlog.

---

6) اقلام عملی برای شروع (Ready-to-use)

• الگوی سیاست برد QA (Sticky):
  • «آیتم جدید شروع نمی‌شود اگر WIP=2 پُر است»؛ «کمک به اتمام > شروع جدید».
• چک‌لیست DoDِ ارتقایافته:
  • Build خودکار سبز + حداقل ۱ تست رگرسیون بحرانی خودکار + معیار پذیرش پاس + همگرایی با اینکریمنت قبلی.
• لیست Enablerها برای اتوماسیون (به بک‌لاگ محصولات اضافه شود):
  • تنظیم CI پایه؛ تست API بحرانی؛ دادهٔ تست پایدار؛ اسکریپت‌سازی Smoke پس از استقرار.
• الگوی جلسه Replenishment:
  • 1. مرور SLE/Cycle Time هفتهٔ قبل، 2) مرور ورودی‌های Ready محصول‌به‌محصول (Owner=PO)، 3) ترکیب Selected واحد برای QA هفتهٔ پیشِ رو.

---

7) سنجه‌ها و داشبورد ۲ هفته‌ای

• Flow: Cycle Time به‌تفکیک کلاس سرویس + درصد آیتم‌های Done قبل از نیمهٔ اسپرینت (Burndown بر حسب PBI Done).
• کیفیت: نرخ عبور تست‌های خودکار در CI + Defect Escape پس از ریلیز.
• انضباط اسکرام: وقوع منظم رویدادها و پایبندی به تایم‌باکس/شفافیت (وظیفهٔ SM برای «حفظ اسکرام»).

---

8) ریسک‌ها و پاسخ‌ها

• تزریق کار خارج از پلن تیم محصول: پاسخ: کانال ورود فقط از بک‌لاگ محصول؛ تسهیلگر محافظِ چارچوب و شفافیت است.
• وابستگی به محیط/دادهٔ تست: پاسخ: Enablerهای زیرساختی را زود و کوچک برنامه‌ریزی کنید؛ در DoD الزام «محیط قابل‌اعتماد».
• کاهش انگیزهٔ اتوماسیون: پاسخ: اتوماسیون را در DoD نهادینه کنید تا «شرط Done» باشد، نه «کاراضافی».

---

9) قرارداد همکاری (Working Agreements)

• Ordering با PO و شفاف در بک‌لاگ؛ تسهیلگر مالک اولویت نیست و فقط شفاف‌سازی/کوچینگ می‌کند.
• WIP محدود و اولویت «تمام کردن» بر «شروع کردن».
• کیفیت = DoD مشترک و قابل‌سنجش؛ بدون DoD، آیتم بخشی از Increment نیست.

---

خروجی مورد انتظار پس از ۲ هفته

• برد «ورودی واحد QA» با سیاست‌های روشن و دادهٔ جریان اولیه.
• DoD به‌روزشده در همهٔ محصولات + حداقل ۱ تست خودکار بحرانی در CI.
• روند Burndown بر حسب PBI Done (نه ساعت) و کاهش چشمگیر چندکارگی.