اللوحات وعناصر العمل

اللوحة في Azure Boards هي مصدر الحقيقة لما يجري العمل عليه وأين وصل. تشرح هذه الصفحة النية والاصطلاحات؛ أما الأعمدة وحدود الـ WIP والقواعد فتعيش في Azure DevOps وهي ما تتبعه فعليًا.

هيكلية عناصر العمل

flowchart TD
  E["Epic<br/>client outcome / big bet"] --> F["Feature<br/>shippable capability"]
  F --> S["Story<br/>one user need, fits a cadence"]
  S --> T["Task<br/>a unit of dev work"]
  S --> B["Bug<br/>defect against a story"]

• Epic — نتيجة كبيرة للعميل، تمتد عبر عدة دورات cadence.
• Feature — شريحة قابلة للتسليم من الـ Epic، تُعرض للعميل في الـ demo.
• Story — حاجة مستخدم واحدة قابلة للاختبار، صغيرة بما يكفي لإنجازها ضمن cadence واحد مدته أسبوعان (انظر دورة التسليم).
• Task / Bug — العمل الفعلي تحت الـ Story. الـ bugs المكتشفة أثناء العمل تُربط بالـ Story الخاصة بها؛ أما bugs الإنتاج فتدخل في الـ expedite lane.

اللوحة وبواباتها

stateDiagram-v2
  [*] --> Ready: DoR met
  Ready --> InDev: pulled within WIP
  InDev --> CodeReview: PR opened
  CodeReview --> QA: approved + merged
  QA --> UAT: passed
  UAT --> Done: sign-off, DoD met
  QA --> InDev: failed
  UAT --> InDev: change requested
  Done --> [*]

الـ Definition of Ready تحكم الدخول إلى اللوحة؛ والـ Definition of Done تحكم الانتقال إلى Done. كلاهما معرّف في دورة التسليم ومكتوب على عمود اللوحة كـ Definition of Done — مرئي للجميع، لكن اللوحة لا تمنعك. فالبطاقة يمكن سحبها من أي عمود إلى أي عمود آخر، إلى الأمام أو إلى الخلف.

حدود الـ WIP لكل عمود

العمود	حد الـ WIP (النية)	لماذا
In Dev	≤ 1–2 لكل مطوّر	أنهِ قبل أن تبدأ الشيء التالي.
Code Review	≤ 1 لكل مُراجِع	الـ PR العالق يوقف اللوحة كلها.
QA	صغير بحجم الفريق	يمنع تكدّس الـ QA الذي يخفي العمل المنجز.
UAT	صغير	يُظهر تأخّر العميل مبكرًا.

ملاحظة

حدود الـ WIP تُضبط في Azure Boards، لا هنا — وهي قيود مرنة (soft): تُبرز اللوحة العمود الذي تجاوز حدّه، لكنها لا تمنعك من تجاوزه. التجاوز بعنصر أو عنصرين أمر طبيعي؛ أمّا العمود المتجاوِز دائمًا فهو موضوع نقاش لا سبب لفشل build. إذا غيّرت حدًا، حدّث هذا الجدول في نفس التغيير.

مسار الـ Expedite

الـ bugs وتذاكر الدعم تمرّ عبر expedite lane مخصص يتجاوز حدود الـ cadence — تُسحب باستمرار، لا تُجمّع في التخطيط. للمسار حد WIP ضيّق خاص به كي لا يبتلع إطفاء الحرائق الفريق كله بهدوء. ومسار التصعيد — L1 ← L2 ← المطوّر الأصلي — معرَّف في نموذج الدعم، وهناك أيضاً تعيش الأسماء.

تسمية الـ Branch والـ Commit مرتبطة بعنصر العمل

كل branch وكل commit يرتبط بمعرّف عنصر العمل ليبقى main قابلاً للتتبّع إلى اللوحة:

• Branch: feature/<id>-short-desc، bugfix/<id>-short-desc، hotfix/<id>-short-desc
• Commit / PR: أشِر إلى #<id> كي يربط Azure DevOps الـ commit والـ PR بعنصر العمل.
• الـ PR يتطلب عنصر عمل مرتبطًا — مفروض عبر branch policy.
• ونوع عنصر العمل يُتحقَّق منه على الـ PR. الـ PR من feature/* يرتبط بـ Story أو Bug، والـ PR من hotfix/* يرتبط بـ Bug. والنوع الخاطئ يُفشل الـ build، لا صبر المراجِع.
• والـ pipeline يحرّك البطاقة. الدمج إلى main ينقل عناصر العمل المرتبطة تلقائيًا — لا تسحبها بيدك، ولا تقاوم ذلك.

انظر الـ Branching والـ Pull Requests لتدفّق الـ Git الكامل.