Dev

1. Figma Structure (Code Structure): https://www.figma.com/board/6xzIFTA6zph9Y8sbKTXNIO/Code-Arch.?node-id=0-1&t=QsNlIosrz7sIZ33g-1

يوضح هذا القسم الهيكل العام للمشروع، وتقسيم الموديولات والصفحات والـ Components، بحيث يكون لدى كل Developer فهم موحد لطريقة بناء النظام قبل كتابة أي سطر كود.

2. List of used lib Docs :

يحتوي على جميع المكتبات والأدوات المستخدمة في المشروع مع روابط التوثيق الرسمية الخاصة بها، لتسهيل التطوير والحفاظ على توحيد أسلوب العمل داخل الفريق.

---

3. Git-Hub:

[

github.com

https://github.com/MagedMRawash/pre-edariba

](https://github.com/MagedMRawash/pre-edariba)

يوضح آلية العمل على المستودع البرمجي (Repository)، واستراتيجية الفروع (Branches)، وقواعد إنشاء الـ Pull Requests، وطريقة التعاون بين أعضاء الفريق.

---

4. Definition of Done (DoD)

يحدد المعايير الإلزامية التي يجب أن تتحقق قبل اعتبار أي Task منتهية، لضمان أن الكود ليس فقط يعمل، بل تم مراجعته واختباره وتوثيقه ونشره بشكل صحيح.

التاسك مش بيتقفل غير لما كل النقط دي تتحقق — مش "خلصت الكود" بس:

4.1. Code & Functionality

•       *   الكود مكتوب ومطابق للـ acceptance criteria المتفق عليها في التاسك.

    *   مفيش أي console.log أو كود تجريبي أو TODOs متسيبة.

    *   الميزة شغالة على كل الحالات: الـ happy path + الـ edge cases + حالات الـ error.

4.2. Code Review

•       *   اتعمل Pull Request، واتراجع واتـ approve من developer تاني (مش self-merge).

    *   كل الـ comments على الـ PR اتحلّت أو اترد عليها.

4.3. Testing

•       *   اتجرّبت يدويًا على الـ pre environment (مش local بس).

    *   لو فيها تكامل مع الـ ETA — اتجرّبت على الـ ETA sandbox وطلعت فاتورة/إيصال صح.

    *   مفيش regression: الميزات القديمة المرتبطة لسه شغالة.

4.4. Documentation

•       *   لو فيه تغيير في الـ API أو الـ behavior → الـ docs على docs.edariba.com اتحدّثت.

    *   أي env variable أو خطوة setup جديدة اتكتبت.

4.5. Deployment & Sign-off

•       *   اتعمل merge للـ main واتـ deploy للـ staging بنجاح من غير ما يكسر الـ build.

    *   QA عمل sign-off (للتاسكات اللي ليها واجهة مستخدم أو bug fix).

    *   التاسك اتنقل لـ "Done" في ClickUp + اتقفل أي bug log مرتبط بيه.

القاعدة: "It works on my machine" مش Done. الـ DoD بيقفل التاسك مش الـ developer.

---

4. نظام نقاط القصص (Story Points System)

يحدد هذا القسم آلية تقدير حجم وجهد المهام التقنية باستخدام نظام Story Points، لضمان تقدير واقعي وموحد داخل الفريق، وتحسين دقة التخطيط عبر الـ Sprints.

4.1. ما هي الـ Story Points؟

•   الـ Story Points هي وحدة قياس تقديرية تعكس حجم الجهد الإجمالي المطلوب لإنجاز مهمة، وليس فقط الوقت. هي بتشمل: التعقيد التقني، حجم الشغل، والغموض أو المخاطر.

•   الـ Points مش ساعات — نفس التاسك ممكن ياخد من Senior ساعة ومن Junior ٣ ساعات، لكن الاتنين يقدّروا نفس الـ Points لأن الحجم واحد.

4.2. سلسلة فيبوناتشي (Fibonacci Scale)

•       *   نستخدم سلسلة فيبوناتشي لتقدير المهام: 1 – 2 – 3 – 5 – 8 – 13

    *   أي مهمة تقديرها أكتر من 13 نقطة لازم تتقسم لتاسكات أصغر (Decompose) قبل ما تبدأ.

النقاط	الوصف	مثال
1	تغيير بسيط جداً — مش محتاج تفكير	تعديل نص، تغيير لون، إضافة حقل بسيط
2	شغل بسيط وواضح — مفيش مفاجآت	إضافة زرار بسيط، تعديل API endpoint موجود
3	شغل متوسط — محتاج شوية تفكير وتجربة	إضافة حقل جديد مع validation، تعديل logic موجود
5	شغل متوسط لمتقدم — فيه تعقيد أو تكامل	إضافة ميزة جديدة فيها تكامل مع ETA API، أو تعديل flow كامل
8	شغل متقدم — معقد أو فيه مجهود كبير	بناء صفحة كاملة من الصفر، أو تكامل مع نظام خارجي جديد
13	شغل كبير جداً — آخر حد قبل ما نقسمه	ميزة كبيرة تشمل backend + frontend + تكامل + اختبار كامل

4.3. كيف نقدّر (Estimation Process)

•   Planning Poker: كل Developer يقدّر التاسك بشكل مستقل (على أساس الحجم مش الوقت)، وبعدين نتكلم عن الفرق في التقديرات.

•   لو فيه فرق كبير في التقديرات (مثلاً واحد قال 2 والتاني قال 8) — ده معناه إن فيه سوء فهم للـ scope أو إن التاسك محتاج توضيح أكتر.

•   لازم نتفق على رقم واحد قبل ما التاسك يدخل الـ Sprint.

4.4. السعة (Velocity)

•   الـ Velocity هو مجموع النقاط اللي الفريق بيحققها في Sprint واحد (عدد التاسكات اللي اتنقلت لـ Done × نقاطها).

•   بيتم حساب الـ Velocity كـ متوسط آخر 3 Sprints، وبناءً عليه بنقدر نعرف كم نقطة نقدر نأخذ في الـ Sprint الجاي.

•   الـ Velocity مش هدف يتحقق — هو مقياس واقعي يساعدنا نخطط أحسن.

4.5. قواعد مهمة

•   التقدير مسؤولية المطور: اللي هيشتغل على التاسك هو اللي يقدّره. مفيش حد يفرض تقدير على حد.

•   التقدير ليس التزام زمني: لو التاسك 5 نقاط، ده مش معناه 5 ساعات. ده معناه إن حجمه 5 بالنسبة لتاسك 3 نقاط.

•   إعادة التقدير مسموحة: لو أثناء الشغل اكتشفت إن التاسك أكبر من التقدير، بلّغ فوراً واتناقشنا على تقدير جديد — ده مش مشكلة، عدم الإبلاغ هو المشكلة.

•   Bug fixes عادةً 1-3 نقاط — لو Bug أخد أكتر من 5 نقاط، يبقى ده مش Bug ده Task.

---

5. Deadlines & Accountability

يوضح فلسفة الفريق في إدارة المواعيد النهائية، وتحمل المسؤولية، وآلية التعامل مع التأخير أو المعوقات، بهدف بناء ثقافة تعتمد على الشفافية والالتزام.

5.1 القواعد الأساسية:

مجموعة من القواعد الأساسية التي تنظم عملية التقدير، والإبلاغ المبكر عن المخاطر، وإدارة الـ blockers قبل أن تؤثر على سير العمل.

•   الـ Estimation مسؤوليتك. انت اللي بتقدّر التاسك (عبر نظام الـ Story Points — راجع القسم 4)، مش حد بيفرض عليك تقدير. لو التاسك أخد نقاط أكتر من تقديرك باستمرار، دي مشكلة استيميشن نتعامل معاها ونحسّنها — مش مشكلة ديدلاين.

•   بلّغ بدري، مش بعد فوات الأوان. لو شايف إنك مش هتلحق الديدلاين، لازم تبلّغ قبلها بـ 24 ساعة على الأقل مش يوم التسليم. التبليغ المبكر = مفيش مشكلة. السكوت لحد ما الديدلاين يعدّي = المشكلة.

•   البلوكر مالكوش حجة لو سكتّ عنه. أي حاجة مبلوكاك (انتظار رد، صلاحية، اعتماد على حد تاني) تتكتب في التاسك على طول وتترفع.

5.2 Escalation Ladder:

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

المرة	الإجراء
أول مرة (مع تبليغ مسبق)	عادي تمامًا — نعيد الـ planning، نشوف البلوكر كان إيه.
تأخير متكرر بدون تبليغ	1:1 لتشخيص السبب الحقيقي (تقدير نقاط القصص؟ scope؟ مهارة؟ تنظيم؟).
نمط مستمر	review رسمي مكتوب + خطة تحسين بمدة محددة.
بعد خطة التحسين بدون تغيير	مراجعة لاستمرار الدور.

الهدف من الـ Deadlines ليس الضغط، بل بناء الثقة والالتزام. التواصل المبكر يحل المشكلة، أما الصمت فهو ما يخلقها.