الحلقة اليومية

عملك حلقة، لا جدول زمني. نحن لا ننشر يومًا مقسّمًا بالساعات عن قصد — فالمختصون لدينا موزّعون على مشاريع متزامنة، وأي جدول كهذا سيصبح خاطئًا بحلول الثلاثاء. ما لا يتغيّر هو الدورة التي تنفّذها والترتيب الذي تنفّذها به.

هذه الصفحة تملك التسلسل فقط. وهي لا تعيد ذكر القواعد — كل خطوة تربط إلى الصفحة التي تملكها. وإذا ظهر رقم أو حدّ هنا وفي مكان آخر، فالصفحة الأخرى هي المرجع.

flowchart TD
  S["Start of day<br/>clear your review queue"] --> P["Pull one item<br/>within WIP limit"]
  P --> V{"Meets Definition<br/>of Ready?"}
  V -- No --> BK["Comment, tag the BA,<br/>pull the next item"]
  BK --> P
  V -- Yes --> B["Build<br/>branch = work-item id"]
  B --> BL{"Blocked?"}
  BL -- Yes --> TL["Team lead — same day"]
  TL --> B
  BL -- No --> PR["Open PR<br/>small, self-reviewed, linked"]
  PR --> R["Review + green build"]
  R --> Q["Hand to QA<br/>with test notes"]
  Q --> D["Done — DoD met"]
  D --> P

الحلقة خطوة بخطوة

١. أفرغ قائمة الـ review قبل أن تكتب كودًا. الـ PR المفتوح يعطّل عمل شخص آخر، أما story لم تبدأها فلا تعطّل أحدًا. الـ SLA للمراجعة هو نفس يوم العمل، وعمود Code Review محدود بـ WIP يقارب ١ لكل مراجع — وكلاهما يعني أن المراجعة تأتي أول النهار لا آخره. → Branching & Pull Requests

٢. اسحب عنصرًا واحدًا — ولا تتجاوز حدّ الـ WIP. اسحب من أعلى عمود Ready. عمود In Dev محدود بـ ١–٢ لكل مطوّر. إذا بلغت الحد فلا تبدأ شيئًا جديدًا، بل اذهب لتساعد في إنهاء شيء قيد التنفيذ. → حدود الـ WIP لكل عمود

٣. تحقّق من Definition of Ready قبل البدء. إذا فشلت الـ story في الـ DoR، فـ لا تبدأها. علّق على الـ work item، اذكر الـ BA، واسحب العنصر الجاهز التالي. البدء بـ story غير جاهزة هو منشأ معظم إعادة العمل ونزاعات النطاق — يبدو تصرفًا متعاونًا ويكلّف أسبوعًا. → Definition of Ready

٤. ابنِ بخطوات صغيرة قابلة للتتبع. الـ branch باسم feature/<id>-short-desc، والـ commits تشير إلى #<id>. أبقِ التغيير صغيرًا بما يكفي لتكون المراجعة حقيقية لا ختمًا شكليًا — استهدف ≤ ٤٠٠ سطر تقريبًا. → تسمية الـ branch والـ commit

٥. تعطّلت؟ إلى قائد الفريق في نفس اليوم. لا في standup الغد. الـ standup يُظهر المعوّقات ولا يحلّها. وسجّلها على الـ work item أيضًا — فما ليس على الـ board ليس موجودًا. → تصعيد المعوّقات

٦. افتح الـ PR — واقرأ diff الخاص بك أولًا. راجع نفسك قبل أن تطلب مراجعة غيرك. اربط الـ work item، واذكر ما تغيّر ولماذا وكيف اختبرته، مع صور لأي تغيير في الواجهة. يجب أن يكون الـ build أخضر. مراجع واحد كحدّ أدنى — واثنان في الـ backend أو الأمان أو حين يكون الكاتب junior. → ما الذي يجعل وصف الـ PR جيدًا

٧. سلّم إلى QA مع ملاحظات اختبار، ثم أنهِ. أخبر QA بما تغيّر وأين ينظر. “Done” تعني الـ Definition of Done كاملة — الـ merge وحده ليس إنهاءً. → Definition of Done

غير قابل للتفاوض

القاعدة	لماذا
لا تدمج أبدًا دون موافقة و build أخضر	سياسة الـ branch تفرضها. لا تبحث عن التفاف عليها.
الـ board يطابق الواقع قبل أن تنهي يومك	الـ board هو مصدر الحقيقة. لوحة قديمة تحوّل الـ standup إلى تخمين.
المعوّق يذهب إلى قائد الفريق في نفس اليوم	إذا بات ليلة، كلّف يومًا لم يخطط له أحد.
لا تبدأ story تفشل في الـ DoR	أرخص لحظة لإصلاح story سيئة هي قبل بدئها.
أسئلة العميل تمرّ عبر الـ PM	جهة اتصال واحدة لكل عميل. الإجابة في رسالة خاصة تتحوّل إلى التزام لم يسعّره أحد.
nit: تعني غير معطِّلة — وما عداها معطِّل	لا تُخمّن أي التعليقات يجب أن تعالجها.

مثال تطبيقي — story من البداية إلى النهاية

الاثنين ٠٩:٣٥ — يفتح Hamza الـ board. هناك PR اثنان بانتظار مراجعته. ينجزهما قبل أن يلمس عمله: واحد بالموافقة، وآخر بتعليق nit: وتعليق معطِّل.

الاثنين ١٠:٠٠ — standup، عشر دقائق. أمس / اليوم / المعوّقات.

الاثنين ١٠:١٥ — يسحب DW-412 «استرجاع مبلغ طلب مدفوع» من عمود Ready. لديه عنصر واحد In Dev، أي أنه تحت الحد.

الاثنين ١٠:٢٠ — فحص الـ DoR. معايير القبول مكتوبة، لكن شكل استجابة الاسترجاع غير متفق عليه مع الـ frontend — وهذا فشل في البند الرابع من الـ DoR، أي تحديد الاعتماديات. لذلك لا يبدأ. يعلّق على DW-412 ويذكر Samaha (BA) و Kenana (Frontend Lead)، ثم يسحب الـ story الجاهزة التالية.

الاثنين ١٤:٠٠ — تم الاتفاق على الـ contract وإضافته إلى الـ work item. ينقل DW-412 إلى In Dev وينشئ feature/412-refund-order.

الثلاثاء ١١:٠٠ — بيئة الـ sandbox لمزوّد الدفع ترفض الاسترجاع الجزئي. هذا معوّق. يسجّله على الـ work item ويبلغ Firas Darwish (Backend Lead) فورًا — لا في standup الأربعاء. يحوّله Firas إلى الـ PM لأن حلّه يحتاج حساب المزوّد لدى العميل.

الأربعاء ٠٩:٠٠ — انحلّ المعوّق. يستأنف البناء.

الأربعاء ١٦:٣٠ — فُتح الـ PR: ١٨٠ سطرًا، الـ work item مربوط، والوصف يذكر ما ولماذا وكيف اختُبر. يقرأ diff نفسه أولًا ويصلح شيئين قبل طلب المراجعة. الكاتب junior، فالمراجعان اثنان: Bakri و Firas Darwish.

الخميس ١٠:٠٠ — موافقة، والـ build أخضر. ينفّذ squash-merge ويحذف الـ branch.

الخميس ١٠:٠٥ — ينقل DW-412 إلى QA مع ملاحظة: «استرجاع جزئي وكامل، مزوّد sandbox، تحقّق من سجل التدقيق.» يلتقطها Abdulaziz مقابل معايير القبول.

الجمعة — نجحت QA، ووقّع العميل في الـ UAT، واكتملت الـ DoD. Done.

أربعة أيام، واليوم الوحيد الضائع بسبب معوّق المزوّد كان ظاهرًا من اليوم الأول بدلًا من أن يظهر في الـ demo.

كيف تبدو الحلقة السيئة

• ثلاث stories في In Dev ولا واحدة مكتملة.
• PR مفتوح أربعة أيام لأن المراجعة تحدث «عند توفر الوقت».
• story بدأت قبل الـ DoR ثم أُعيد تحديد نطاقها أثناء البناء.
• معوّق يُذكر لأول مرة في demo العميل.
• الـ board يُحدَّث مرة واحدة الخميس عن الأسبوع كله.

كل واحدة من هذه هي الفشل نفسه: عمل بدأ ولم ينتهِ. حدود الـ WIP وبوابة الـ DoR موجودة تحديدًا لتجعل ذلك مرئيًا وهو ما يزال رخيصًا.