> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # Agile بلا شعارات: Scrum وKanban كما يطبقان فعلاً - URL: https://arabroot.io/articles/agile-و-scrum-و-kanban-بلا-شعارات/ - Published: 2026-10-08T20:00:00.000Z - Updated: 2026-10-09T13:01:49.000Z - Description: من أين جاءت Agile، وكيف تعمل Scrum وKanban كما تصفها أدلتها الرسمية، وما الأخطاء التي تحولها إلى اجتماعات بلا فائدة. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الفرق والمنتج, DevOps وCI/CD, تطبيقات لفريقك, الاستضافة الذاتية لنفرض أن فريقك يقول إنه يعمل بأسلوب Scrum، ففيه اجتماع يومي Daily Scrum كل صباح يستمر أربعين دقيقة، وسبرنتات Sprints من أسبوعين، ونقاط تقدير Story Points ترفع إلى الإدارة كل أسبوع، ولوحة مهام Task Board فيها عمود اسمه «تم» Done، ومع ذلك فالإصدار يخرج إلى العملاء كل ثلاثة أشهر، وكل سبرنت ينتهي بقائمة مهام «شبه منتهية» تنتقل إلى السبرنت التالي، والاختبار يحدث في سبرنت لاحق، والمدير يقارن بين الفرق بعدد النقاط. وهذا الفريق في الحقيقة يعمل بالطريقة القديمة نفسها، ولكن بأسماء جديدة، والسبب أن ما انتقل إليه هو الاجتماعات والمصطلحات، وأما الشيء الذي جاءت Agile من أجله، وهو أن ترى برنامجاً يعمل في يد المستخدم بعد أسابيع قليلة ثم تعدل خطتك بناءً على ما تعلمته، فلم ينتقل. لذلك سوف نبدأ في هذا المقال من المصادر الأصلية نفسها: الورقة التي يقال إنها اخترعت الشلال Waterfall وهي في الحقيقة حذرت منه، وكيف ظهرت Scrum وXP وبيان Agile، ثم Scrum كما يصفها [دليل Scrum الرسمي لسنة 2020](https://scrumguides.org/scrum-guide.html?ref=arabroot.io)، وKanban كما يصفها [دليل Kanban](https://kanbanguides.org/english/?ref=arabroot.io)، وسوف نناقش فيه ما يلي: - من أين جاءت Agile، وما الذي قاله Royce سنة 1970 فعلاً، وما الذي اتفق عليه سبعة عشر شخصاً في Snowbird سنة 2001. - Scrum بمسؤولياتها الثلاث وأحداثها الخمسة ومخرجاتها الثلاثة، ثم مثال سبرنت من أسبوعين يوماً بيوم. - Kanban وحدود العمل الجاري WIP Limits وزمن الإنجاز Cycle Time وقانون Little، وممارسات XP التقنية التي تنساها أغلب الفرق. - التقدير بالنقاط والسرعة Velocity وحركة #NoEstimates، وأطر التوسع SAFe وLeSS مع النقد الموثق لها. - الأخطاء التي تجعل Scrum بالاسم فقط، وما الذي تقيسه بدل النقاط، والأدوات مفتوحة المصدر التي تشغلها على سيرفرك. وإذا كان فريقك يستخدم أدوات الذكاء الاصطناعي في كتابة الكود، فما الذي يتغير في هذا كله قد خصصنا له مقالاً مستقلاً هو [Agile في عصر الذكاء الاصطناعي](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/)، وأما هنا فنضع الأساس الذي يبنى عليه. ## من أين جاءت Agile؟ الصورة التالية تبين المحطات الرئيسية بالترتيب، ولكل محطة منها مصدر أصلي منشور سوف نرجع إليه في الفقرات التالية: ![خط زمني من 1970 إلى 2025: ورقة Royce في WESCON سنة 1970 مع عبارة risky and invites failure، ثم مقال Takeuchi وNonaka في HBR سنة 1986، ثم Scrum عند Jeff Sutherland في Easel سنة 1993، وعرضها في OOPSLA سنة 1995، وXP مع Kent Beck في مشروع Chrysler C3 في منتصف التسعينيات، وبيان Agile في Snowbird سنة 2001 بسبعة عشر شخصاً وأربع قيم واثني عشر مبدأ، ونظام السحب Kanban عند David J. Anderson في Microsoft سنة 2004، وكتابه ودليل Scrum الأول سنة 2010، ودليل Scrum سنة 2020، ودليل Kanban سنة 2025](https://arabroot.io/content/images/2026/10/agile-scrum-01-timeline.webp) محطات Agile من ورقة Royce سنة 1970 حتى دليل Kanban سنة 2025 ### ورقة Royce سنة 1970: الشلال Waterfall الذي حذر منه صاحبه كل كتاب تقريباً يبدأ قصة Agile بالشلال Waterfall، أي أن تجمع المتطلبات Requirements كلها، ثم تصمم، ثم تكتب الكود، ثم تختبر، ثم تسلم، وكل مرحلة تبدأ بعد أن تنتهي التي قبلها. والمرجع الذي ينسب إليه هذا النموذج عادة هو ورقة Winston W. Royce بعنوان [Managing the Development of Large Software Systems](https://web.archive.org/web/20220223165619id%5F/https://www.praxisframework.org/files/royce1970.pdf) التي نشرت في Proceedings, IEEE WESCON في أغسطس 1970، ولكن من يقرأ الورقة نفسها سوف يجد أن كلمة Waterfall غير موجودة فيها أصلاً، وأن Royce بعد أن رسم المراحل متتابعة في الشكل الثاني كتب مباشرة أنه يؤمن بالفكرة «but the implementation described above is risky and invites failure»، والسبب الذي ذكره أن الاختبار في نهاية الدورة هو أول مرة يرى فيها الفريق التوقيت والذاكرة وتبادل البيانات على حقيقتها، فإذا ظهرت مشكلة في التصميم هنا فقد تعود إلى البداية، ويتضاعف الوقت والتكلفة. واقترح Royce في الورقة نفسها خمس خطوات لتقليل هذا الخطر: أن يأتي تصميم البرنامج قبل التحليل، وأن يوثق التصميم بشكل كبير، وأن تنفذ المشروع مرتين بحيث تكون النسخة الأولى تجربة مصغرة Pilot تكشف المشاكل، وأن تخطط للاختبار وتراقبه، وأن تشرك العميل بشكل رسمي في أكثر من نقطة قبل التسليم. ولاحظ أن Royce لم يكن يدعو إلى Agile، فهو يطلب توثيقاً كثيراً، ولكنه كان يعرف قبل خمسين سنة أن التعلم المتأخر هو أغلى شيء في المشروع، وهذه هي الفكرة التي سوف تبني عليها كل الأساليب التالية: ![في الأعلى مراحل ورقة Royce متتابعة كالدرج من SYSTEM REQ إلى OPERATIONS، والاختبار TESTING هو أول تغذية راجعة حقيقية، وسهم أحمر يعود منه إلى البداية، وبجانبها إصلاحات Royce الخمسة، وفي الأسفل أربعة سبرنتات من أسبوعين يخرج من كل منها Increment يعمل، ويراه المستخدمون فيعدلون الخطة التالية](https://arabroot.io/content/images/2026/10/agile-scrum-02-waterfall-vs-iterative.webp) في المسار الواحد يأتي أول رد فعل حقيقي Feedback عند الاختبار Testing، وفي الدفعات القصيرة Iterations يأتي كل أسبوعين ### Scrum وXP في التسعينيات جاء اسم Scrum من مقال Hirotaka Takeuchi وIkujiro Nonaka في Harvard Business Review سنة 1986 بعنوان [The New New Product Development Game](https://hbr.org/1986/01/the-new-new-product-development-game?ref=arabroot.io)، حيث شبها فرق تطوير المنتجات الناجحة في الشركات اليابانية بفريق الرجبي Rugby الذي يتقدم بالكرة معاً، بدل فريق التتابع الذي يسلم فيه كل عداء العصا لمن بعده. وكما يذكر [مسرد Agile Alliance](https://www.agilealliance.org/glossary/scrum/?ref=arabroot.io) استخدم Jeff Sutherland هذه الفكرة كطريقة عمل في شركة Easel سنة 1993، ثم عرضها هو وKen Schwaber معاً في مؤتمر OOPSLA سنة 1995، وهي المعلومة نفسها التي يذكرها [دليل Scrum](https://scrumguides.org/scrum-guide.html?ref=arabroot.io) في فقرة تاريخه. وأما الدليل الرسمي نفسه فقد صدر أول مرة سنة 2010، ثم عدل عدة مرات كما في [صفحة التعديلات](https://scrumguides.org/revisions.html?ref=arabroot.io) حتى نسخة 2020 التي ما زالت هي النسخة الحالية. وفي الفترة نفسها كان Kent Beck يجمع مجموعة من الممارسات التقنية في مشاريع Smalltalk، وكما يقول [Martin Fowler](https://martinfowler.com/bliki/ExtremeProgramming.html?ref=arabroot.io)، الذي عمل معه، فإن هذه الممارسات استخدمت معاً لأول مرة في مشروع الرواتب C3 في شركة Chrysler في منتصف التسعينيات، ثم أخذت اسم البرمجة القصوى Extreme Programming واختصاراً XP، ووصفها Beck في كتابه Extreme Programming Explained. والفرق بين الاثنين مهم: Scrum تنظم العمل والأدوار والاجتماعات ولا تقول لك كيف تكتب الكود، وXP تهتم بالكود نفسه، مثل الاختبار أولاً Test-First والتكامل المستمر Continuous Integration والبرمجة الثنائية Pair Programming، ولذلك تجد فرقاً كثيرة ناجحة تجمع بينهما. ### بيان Agile Manifesto في Snowbird سنة 2001 كما يروي Jim Highsmith في [صفحة تاريخ البيان](https://agilemanifesto.org/history.html?ref=arabroot.io)، اجتمع سبعة عشر شخصاً من 11 إلى 13 فبراير 2001 في منتجع Snowbird للتزلج في ولاية Utah، وكانوا يمثلون أساليب مختلفة: XP وScrum وDSDM وAdaptive Software Development وCrystal وFeature-Driven Development وPragmatic Programming، ومنهم Kent Beck وMartin Fowler وRon Jeffries وAlistair Cockburn وBob Martin، فاتفقوا على [بيان قصير](https://agilemanifesto.org/?ref=arabroot.io) فيه أربع قيم Values، كل واحدة منها تفضل شيئاً على شيء آخر: الأفراد والتفاعل بينهم Individuals and Interactions أهم من العمليات والأدوات Processes and Tools، والبرنامج الذي يعمل Working Software أهم من التوثيق الشامل Comprehensive Documentation، والتعاون مع العميل Customer Collaboration أهم من التفاوض على العقد Contract Negotiation، والاستجابة للتغيير Responding to Change أهم من اتباع الخطة Following a Plan. وأول قيمة منها بنصها هي: > Individuals and interactions over processes and tools ولاحظ أن البيان نفسه يقول إن الأشياء التي على اليمين لها قيمة، ولكن الأشياء التي على اليسار أهم، أي أن Agile لا تلغي التوثيق ولا الخطة ولا العقد، وإنما ترتب الأولويات عند التعارض، وهذه أول نقطة تفهم خطأ في كثير من الفرق التي تقول «نحن Agile ولا نكتب توثيقاً». ومع القيم الأربع كتبوا [اثني عشر مبدأ Principles](https://agilemanifesto.org/principles.html?ref=arabroot.io)، ويمكن أن تجمعها في أربع أفكار: أن تسلم برنامجاً يعمل بشكل متكرر، من أسبوعين إلى شهرين مع تفضيل المدة الأقصر، وأن يكون هذا البرنامج هو المقياس الأول للتقدم، وأن تقبل تغيير المتطلبات حتى في وقت متأخر، وأن يعمل الأشخاص من جهة العمل Business والمطورون معاً كل يوم في فريق متحفز يثق به من حوله، وأن تحافظ على وتيرة عمل يمكن الاستمرار عليها Sustainable Pace مع اهتمام دائم بالجودة التقنية والتصميم الجيد والبساطة، أي أن تتقن عدم عمل ما لا يلزم، وأن يتوقف الفريق على فترات منتظمة ليراجع طريقة عمله ويعدلها. وكما ترى فلا يوجد في المبادئ الاثنا عشر أي ذكر للاجتماع اليومي ولا للنقاط ولا للوحة المهام، فهذه كلها أدوات جاءت من أساليب محددة لاحقاً. ### Kanban في البرمجيات: من المصانع إلى David J. Anderson كلمة Kanban يابانية وتعني البطاقة أو الإشارة المرئية، وأصلها كما يقول دليل Kanban University في التصنيع الرشيق Lean Manufacturing، حيث لا تبدأ محطة العمل قطعة جديدة إلا عندما تطلبها المحطة التي بعدها، أي نظام سحب Pull بدل نظام الدفع Push. وكما يذكر [مسرد Agile Alliance](https://www.agilealliance.org/glossary/kanban/?ref=arabroot.io) طبق David J. Anderson نظام سحب من هذا النوع على قسم تقنية المعلومات في Microsoft سنة 2004، ثم صاغ ما سماه طريقة Kanban في شركة Corbis بين 2006 و2007، ونشر كتابه Kanban: Successful Evolutionary Change for Your Technology Business سنة 2010، وهو المرجع الذي يبني عليه [دليل Kanban University](https://kanban.university/kanban-guide/?ref=arabroot.io). والفكرة الأساسية هنا مختلفة عن Scrum، فطريقة Kanban لا تفرض عليك أدواراً ولا سبرنتات، وإنما تبدأ من طريقة عملك الحالية كما هي، وتجعلها مرئية، ثم تضع حداً لعدد الأعمال الجارية في نفس الوقت، وتحسن التدفق خطوة خطوة. ## Scrum كما يصفها دليل 2020 أول شيء يجب أن تعرفه أن [دليل Scrum](https://scrumguides.org/scrum-guide.html?ref=arabroot.io) صغير جداً، فهو أقل من ثلاث عشرة صفحة كما تقول صفحة التعديلات، ويقول عن نفسه إن الإطار ناقص عن قصد Purposefully Incomplete، أي أنه يعرف الأجزاء اللازمة فقط ويترك لك الممارسات الأخرى، ولذلك فإن كثيراً مما تراه في الشركات باسم Scrum، مثل قصص المستخدمين User Stories ونقاط التقدير والسرعة Velocity ولوحة المهام، غير موجود في الدليل أصلاً. وفي نسخة 2020 تحديداً، وكما في [صفحة التعديلات](https://scrumguides.org/revisions.html?ref=arabroot.io)، أصبح الدليل أقل إلزاماً، فحذف الأسئلة الثلاثة المشهورة في الاجتماع اليومي، وألغى فكرة «الفريق داخل الفريق» فصار هناك فريق Scrum واحد فيه ثلاث مسؤوليات، وأضاف هدف المنتج Product Goal. والصورة التالية تبين الدورة كاملة: ![فريق Scrum واحد من عشرة أشخاص أو أقل فيه Product Owner وScrum Master وDevelopers، والدورة تبدأ من Product Backlog والتزامه Product Goal، ثم Sprint Planning بحد أقصى ثماني ساعات لسبرنت من شهر، ثم Sprint Backlog والتزامه Sprint Goal، ثم Sprint لا يزيد عن شهر وفيه Daily Scrum لمدة 15 دقيقة، ثم Increment والتزامه Definition of Done، ثم Sprint Review بحد أقصى أربع ساعات، ثم Retrospective بحد أقصى ثلاث ساعات، ثم يبدأ السبرنت التالي، وما تعلمه الفريق في المراجعة يعود إلى Product Backlog](https://arabroot.io/content/images/2026/10/agile-scrum-03-scrum-cycle.webp) دورة Scrum بأحداثها الخمسة ومخرجاتها الثلاثة والتزام كل مخرج منها ### ثلاث مسؤوليات Accountabilities، وليست ثلاث وظائف فريق Scrum صغير، وفي العادة عشرة أشخاص أو أقل كما يقول الدليل، والسبب أن الفريق الأصغر يتواصل بشكل أفضل، وإذا كبر الفريق فالدليل ينصح بأن ينقسم إلى عدة فرق كل منها يركز على نفس المنتج. وفي داخل الفريق لا توجد فرق فرعية ولا تسلسل إداري Hierarchy، وإنما ثلاث مسؤوليات Accountabilities: - **مالك المنتج Product Owner:** مسؤول عن أن يحقق عمل الفريق أكبر قيمة للمنتج، وعن إدارة قائمة المنتج Product Backlog، أي أنه يكتب هدف المنتج ويشرحه، ويضيف العناصر ويرتبها. والدليل يقول صراحة إنه شخص واحد وليس لجنة، ومن يريد أن يغير القائمة عليه أن يقنعه. - **Scrum Master:** مسؤول عن فعالية الفريق، ومن ذلك أن يدرب الفريق على الإدارة الذاتية Self-Management، وأن يتسبب في إزالة العوائق Impediments، وأن تحدث الأحداث كلها في وقتها وضمن مدتها. وهو ليس مدير مشروع يوزع المهام، وليس سكرتيراً يدير الاجتماعات. - **المطورون Developers:** كل من يعمل على بناء جزء من المنتج، سواءً كان يكتب الكود أو يختبر أو يصمم أو يكتب التوثيق، والدليل يقول إنه يستخدم كلمة Developers للتبسيط لا للاستبعاد. وهم مسؤولون عن خطة السبرنت، وعن الجودة بالالتزام بتعريف الإنجاز Definition of Done، وعن تعديل خطتهم كل يوم نحو هدف السبرنت. وقد يتساءل البعض: هل يجب أن يكون في الشركة شخص وظيفته Scrum Master؟ والإجابة أن الدليل يتحدث عن مسؤوليات لا عن مسميات وظيفية، ففي فريق صغير قد يحمل هذه المسؤولية أحد المطورين، والمهم ألا يجمع شخص واحد بين مسؤولية مالك المنتج ومسؤولية Scrum Master، والسبب أن الأول يضغط باتجاه المزيد من الميزات والثاني يحمي طريقة العمل والجودة، وعندما يجتمعان في شخص واحد يخسر الثاني غالباً. ### الأحداث الخمسة Events ومدة كل منها كل حدث في Scrum فرصة لفحص Inspect شيء ما ثم تعديله Adapt، ولكل حدث مدة قصوى Timebox، والمدد في الدليل مكتوبة لسبرنت من شهر، وللسبرنتات الأقصر تكون الأحداث أقصر عادة: | الحدث Event | الغرض منه | المدة القصوى Timebox لسبرنت من شهر | | ------------------------------------ | ------------------------------------------------------------------------------- | ---------------------------------- | | السبرنت Sprint | الوعاء الذي تحدث فيه كل الأحداث الأخرى، ويبدأ التالي فور انتهاء السابق | شهر أو أقل بطول ثابت | | تخطيط السبرنت Sprint Planning | لماذا هذا السبرنت مهم، وما الذي يمكن إنجازه، وكيف | 8 ساعات | | الاجتماع اليومي Daily Scrum | فحص التقدم نحو هدف السبرنت وتعديل الخطة | 15 دقيقة | | مراجعة السبرنت Sprint Review | جلسة عمل مع أصحاب المصلحة Stakeholders لفحص ما تم إنجازه وتعديل الخطوات التالية | 4 ساعات | | استعادة السبرنت Sprint Retrospective | تحسين الجودة وطريقة عمل الفريق، وهو الحدث الذي يختم السبرنت | 3 ساعات | وفي الإعداد أعلاه لاحظ التالي: - الدليل يقول إن مراجعة السبرنت جلسة عمل، وعلى الفريق ألا يجعلها عرضاً تقديمياً Presentation، والسبب أن الهدف منها أن يتغير ما بعدها بناءً على ما يقوله المستخدمون، لا أن يصفق الحاضرون. - الاجتماع اليومي للمطورين، وغرضه هدف السبرنت، والدليل يقول صراحة إنه ليس الوقت الوحيد الذي يعدل فيه المطورون خطتهم، فهم يتحدثون طوال اليوم. - تحسين القائمة Product Backlog Refinement ليس حدثاً مستقلاً في الدليل، وإنما نشاط مستمر يقسم فيه الفريق العناصر الكبيرة إلى عناصر أصغر وأوضح، وكيف تكتب هذه العناصر نفسها هو موضوع هندسة المتطلبات Requirements Engineering: [![](https://arabroot.io/content/images/2026/10/requirements-engineering-cover-cover.webp)دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.](https://arabroot.io/articles/%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-requirements-engineering/)[![](https://arabroot.io/content/images/2026/10/requirements-practice-cover-cover.webp)دليلمن فكرة غامضة إلى متطلبات Requirements واضحة: مثال عملي مع القوالبكيف تحول جملة «نبغى نظام حجز مواعيد لعيادة» إلى متطلبات Requirements واضحة يمكن بناؤها واختبارها، مع قوالب جاهزة للنسخ.](https://arabroot.io/articles/%D9%85%D9%86-%D9%81%D9%83%D8%B1%D8%A9-%D8%BA%D8%A7%D9%85%D8%B6%D8%A9-%D8%A7%D9%84%D9%89-%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D9%88%D8%A7%D8%B6%D8%AD%D8%A9-%D9%85%D8%AB%D8%A7%D9%84-%D8%B9%D9%85%D9%84%D9%8A/) ### المخرجات الثلاثة Artifacts والتزام كل منها لكل مخرج في Scrum التزام Commitment يجعل التقدم قابلاً للقياس، وهذه من إضافات نسخة 2020: - **قائمة المنتج Product Backlog** والتزامها **هدف المنتج Product Goal**: القائمة مرتبة بما يحتاجه المنتج، والهدف هو الحالة المستقبلية التي يتجه إليها الفريق، فإذا لم تستطع أن تربط عنصراً في القائمة بالهدف فلماذا هو موجود؟ - **قائمة السبرنت Sprint Backlog** والتزامها **هدف السبرنت Sprint Goal**: وهو الهدف الوحيد للسبرنت كما يقول الدليل، ويعطي الفريق مرونة في العمل نفسه، فإذا تبين أن عنصراً أكبر من المتوقع يتفاوض المطورون مع مالك المنتج على النطاق Scope دون أن يمس الهدف. - **الزيادة Increment** والتزامها **تعريف الإنجاز Definition of Done**: وهي خطوة ملموسة نحو هدف المنتج، تعمل مع كل ما سبقها، ويمكن أن يخرج أكثر من Increment في السبرنت الواحد. ### تعريف الإنجاز Definition of Done: السطر الذي يفرق بين «انتهيت» و«انتهيت تقريباً» يقول الدليل إن العنصر الذي لا يحقق تعريف الإنجاز لا يمكن إصداره ولا حتى عرضه في مراجعة السبرنت، وإنما يعود إلى قائمة المنتج. وهذه القاعدة وحدها تحل نصف مشاكل الفرق، والسبب أن كلمة «انتهيت» عند المطور قد تعني أن الكود يعمل على جهازه، وعند فريق الاختبار أنه مر بالاختبارات، وعند مالك المنتج أنه وصل إلى المستخدمين. والمثال التالي تعريف إنجاز لفريق تطبيق ويب صغير، وهو نقطة بداية تعدلها بحسب منتجك: ```text Definition of Done (web team, v1) - Code merged to main through a reviewed pull request - Unit and integration tests written and passing in CI - No new critical findings from SAST and dependency scanning - Acceptance criteria checked by someone other than the author - Deployed to staging and smoke-tested - Feature flag in place if the change is not ready for all users - User-facing text reviewed in Arabic and English - Docs and changelog updated ``` في الإعداد أعلاه لاحظ التالي: - الدمج في `main` عبر مراجعة يفترض أن فريقك يعمل بفروع قصيرة، وهذا ما شرحناه في [التطوير على الفرع الرئيسي Trunk-Based](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%81%D8%B1%D8%B9-%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A-trunk-based/). - الاختبارات في CI بأنواعها شرحناها في [أنواع الاختبارات للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/)، والفحص الأمني جزء من التعريف لا مرحلة بعده، كما في [دورة حياة تطوير البرمجيات الآمنة Secure SDLC](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-sdlc/). - ال Feature Flag يسمح لك بأن تدمج الكود وتنشره قبل أن يراه كل المستخدمين، والتفاصيل في [مفهوم Feature Flags والإطلاق التدريجي](https://arabroot.io/articles/%D9%85%D9%81%D9%87%D9%88%D9%85-feature-flags-%D9%88%D8%A7%D9%84%D8%A7%D8%B7%D9%84%D8%A7%D9%82-%D8%A7%D9%84%D8%AA%D8%AF%D8%B1%D9%8A%D8%AC%D9%8A-gradual-rollout/). - ابدأ بتعريف يستطيع الفريق تحقيقه اليوم، ثم شدده في كل Retrospective، فالتعريف الذي يكتب على الورق ولا يطبق أسوأ من عدم وجوده. ## مثال: سبرنت Sprint من أسبوعين خطوة بخطوة لنأخذ مثالاً من الواقع اليومي لأي فريق SaaS: لنفرض أن لديك فريقاً من أربعة مطورين ومالك منتج وScrum Master يعمل على تطبيق ويب، وأن فريق الدعم يشتكي من أن ربع التذاكر سببها مستخدمون نسوا كلمة المرور. فيضع مالك المنتج في رأس القائمة ميزة استعادة كلمة المرور، ويبدأ الفريق سبرنتاً من أسبوعين، أي عشرة أيام عمل. والصورة التالية تبين السبرنت كله، ثم نمشي عليه يوماً بيوم: ![سبرنت من عشرة أيام هدفه أن يستعيد المستخدم حسابه دون التواصل مع الدعم، وفي اليوم الأول التخطيط، وفي اليوم الخامس تحسين القائمة، وفي اليوم العاشر المراجعة والاستعادة، واجتماع يومي كل يوم، ثم ثلاث لوحات: في اليوم الأول ستة عناصر في To do، وفي اليوم السادس عنصر في Done وعنصر في Review وعنصران في Doing أحدهما rate limit أكبر من المتوقع، وفي اليوم العاشر خمسة عناصر في Done والعنصر السادس يعود إلى قائمة المنتج، وتحتها نتيجة المراجعة مع فريق الدعم ونتيجة الاستعادة](https://arabroot.io/content/images/2026/10/agile-scrum-05-sprint-walkthrough.webp) الخطة تتغير داخل السبرنت Sprint، والذي لا يتغير هو هدف السبرنت Sprint Goal والجودة Quality 1. **اليوم الأول، التخطيط Sprint Planning:** يتفق الفريق كله على هدف السبرنت: «يستطيع المستخدم أن يستعيد حسابه دون التواصل مع الدعم»، ثم يختار المطورون ستة عناصر من القائمة: نموذج طلب الاستعادة، ورسالة بريد فيها رابط برمز Token تنتهي صلاحيته بعد 30 دقيقة، وصفحة تعيين كلمة المرور الجديدة، وتحديد عدد الطلبات Rate Limit حتى لا يستخدم النموذج في إغراق بريد الناس، وتسجيل العملية في سجل التدقيق Audit Log، وقالب البريد بالعربية. ولاحظ أن هذه توقعات Forecast لا وعود، والدليل نفسه يسميها توقعات السبرنت Sprint Forecasts. 2. **كل يوم، الاجتماع اليومي Daily Scrum:** خمس عشرة دقيقة في نفس الوقت والمكان، والسؤال الوحيد الذي يهم: هل ما زلنا في الطريق إلى هدف السبرنت، وما الذي يعيقنا؟ وأما تفاصيل المشكلة التقنية فتناقش بعد الاجتماع بين من يعنيهم الأمر فقط. 3. **اليوم الخامس، تحسين القائمة Refinement:** يجلس الفريق ساعة مع مالك المنتج على عناصر السبرنت القادم، فيقسم الكبير منها ويكتب معايير القبول Acceptance Criteria، حتى لا يبدأ التخطيط القادم بعناصر غامضة. 4. **اليوم السادس، الخطة تتغير:** في الاجتماع اليومي يقول المطور الذي يعمل على تحديد الطلبات إن العمل أكبر مما توقعوا، لأن التطبيق يعمل على أكثر من سيرفر خلف Load Balancer ويحتاج إلى عداد مشترك. والحل البسيط أن يعمل الفريق ساعات إضافية، أو أن يؤجل الاختبار، وكلاهما يخالف الدليل الذي يقول إن الجودة لا تنقص. والطريقة الصحيحة أن يتفاوض المطورون مع مالك المنتج، فيخرج قالب البريد العربي من السبرنت، لأن الهدف يتحقق بالقالب الافتراضي، ويبقى الهدف كما هو. 5. **اليوم العاشر، المراجعة Sprint Review:** يعرض الفريق الميزة وهي تعمل على بيئة staging أمام فريق الدعم، فيطلب الدعم رسالة واضحة عندما تنتهي صلاحية الرابط، فتضاف إلى القائمة مع قالب البريد العربي، ثم يقرر مالك المنتج متى تصل إلى كل المستخدمين. 6. **اليوم العاشر، الاستعادة Retrospective:** يلاحظ الفريق أن طلبات الدمج Pull Requests انتظرت يومين في المتوسط حتى يراجعها أحد، فيتفق على إجراء واحد فقط: مراجعة كل طلب دمج في نفس اليوم، ويضعه في قائمة السبرنت التالي حتى لا ينسى. وإذا أردت أن تطبق هذا المثال في أداة على سيرفرك، فقد شرحنا في [دليل تثبيت Taiga](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-taiga-%D9%84%D8%A5%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9/) كيف تنشئ مشروعاً بقالب Scrum أو Kanban، وتفعل وحدة Backlog والسبرنتات، وتضيف القصص ومعايير قبولها. ## Kanban: حدود العمل الجاري WIP Limits والتدفق Flow هناك اليوم مصدران رئيسيان لKanban في البرمجيات، و[دليل Kanban](https://kanbanguides.org/english/?ref=arabroot.io) الذي كتبه John Coleman وDaniel Vacanti مع آخرين ونسخته الحالية v2025.5 من مايو 2025، يعرفه بثلاث ممارسات: أن تعرف سير العمل Workflow وتجعله مرئياً، وأن تدير الأعمال فيه بشكل نشط، وأن تحسنه باستمرار. وأما [دليل Kanban University](https://kanban.university/kanban-guide/?ref=arabroot.io) المبني على كتاب Anderson فيذكر ست ممارسات عامة أهمها أن تجعل العمل مرئياً، وأن تحد العمل الجاري، وأن تدير التدفق، وأن تجعل قواعد العمل مكتوبة وواضحة. والمصدران يتفقان على الجوهر الذي تبينه الصورة التالية: ![لوحة Kanban بخمسة أعمدة: Backlog دون حد، وReady بحد 3، وIn progress بحد 3 وهو ممتلئ، وReview بحد 2 وهو ممتلئ باللون الأحمر، وDone فيه ثلاثة عناصر هذا الأسبوع، والعنصر 27 انتهى كوده ولا يستطيع الدخول إلى المراجعة، فيساعد مطوره في مراجعة عنصر آخر بدل أن يبدأ عملاً جديداً، وتحت الأعمدة زمن الإنجاز Cycle Time من البدء إلى الانتهاء، وفي الأسفل قانون Little: متوسط زمن الإنجاز يساوي متوسط العمل الجاري على متوسط الإنتاجية، ومع 6 عناصر و3 في الأسبوع يكون أسبوعين، ومع 12 عنصراً بنفس الإنتاجية يكون أربعة أسابيع](https://arabroot.io/content/images/2026/10/agile-scrum-04-kanban-flow.webp) الحد الممتلئ WIP Limit يوقف بدء عمل جديد ويدفع الفريق إلى إنهاء ما بدأه ### مقاييس التدفق Flow Metrics الأربعة يحدد دليل Kanban أربعة مقاييس يجب أن يتابعها الفريق، وكلها تقاس من اللوحة نفسها دون أي تقدير: - **العمل الجاري WIP:** عدد العناصر التي بدأت ولم تنته. - **الإنتاجية Throughput:** عدد العناصر التي انتهت في وحدة زمن، مثل الأسبوع. - **عمر العنصر Work Item Age:** الوقت منذ بدأ العنصر حتى اليوم، وهو أهم مقياس للعناصر التي ما زالت جارية، فالعنصر الذي عمره أربعة أيام في عمود متوسطه يومان يحتاج إلى سؤال اليوم لا بعد أسبوع. - **زمن الإنجاز Cycle Time:** الوقت بين بدء العنصر وانتهائه. ### لماذا تضع حداً للعمل الجاري WIP Limit؟ الحل البسيط الذي تتبعه أغلب الفرق أن يبدأ كل مطور عملاً جديداً كلما انتظر شيئاً، فإذا كانت المراجعة متأخرة يبدأ مهمة أخرى، وإذا كان ينتظر رداً من مالك المنتج يبدأ ثالثة، ويبدو هذا منطقياً لأن أحداً لا يجلس دون عمل. ولكن النتيجة أن كل شخص يحمل أربعة أو خمسة أعمال، وكل عمل منها ينتظر، فلا ينتهي شيء، ويكثر التبديل بين المهام Context Switching. والطريقة الصحيحة أن تضع حداً لكل عمود، فإذا امتلأ عمود المراجعة كما في الصورة لا يبدأ المطور عملاً جديداً، وإنما يساعد في المراجعة حتى يتحرك العمل. وكما تقول [صفحة DORA عن حدود العمل الجاري](https://dora.dev/capabilities/wip-limits/?ref=arabroot.io) فالهدف من الحد أن يكشف المشكلات في النظام حتى تعالجها، ولذلك لا ترفع الحد عندما يتعطل العمل، بل إذا كان الحد سهل التحقيق دائماً فخفضه. ### قانون Little: لماذا يطول الانتظار عندما تبدأ أعمالاً أكثر؟ في سنة 1961 نشر John D. C. Little برهاناً لعلاقة في نظرية الطوابير Queueing Theory صارت تعرف باسمه، وفي [مقاله بمناسبة مرور خمسين سنة عليها](https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf?ref=arabroot.io) يذكر الصيغة التي تستخدمها إدارة العمليات: الإنتاجية تساوي العمل الجاري مقسوماً على زمن الإنجاز. وإذا أعدنا ترتيبها تصبح: ```text Average Cycle Time = Average WIP / Average Throughput WIP 6 items, throughput 3 items/week -> 6 / 3 = 2 weeks WIP 12 items, throughput 3 items/week -> 12 / 3 = 4 weeks ``` ولاحظ أن الفريق نفسه بنفس الإنتاجية تضاعف زمن الإنجاز عنده عندما ضاعف عدد الأعمال التي بدأها، أي أن بدء أعمال أكثر لا يجعلك تنهي أكثر، وإنما يجعل كل عمل ينتظر أطول. ويجدر الانتباه إلى أن العلاقة تنطبق على المتوسطات في فترة يكون فيها النظام مستقراً، أي أن ما يدخل يساوي تقريباً ما يخرج، فلا تستخدمها لتتوقع موعد عنصر واحد بعينه، وإنما لتفهم أثر الحدود على النظام كله. ### Scrum أم Kanban؟ اختر Scrum إذا كان عملك منتجاً تبنيه على دفعات ويستفيد من هدف واضح كل أسبوعين ومن مراجعة منتظمة مع المستخدمين، واختر Kanban إذا كان العمل يصل بشكل مستمر ولا يمكن تخطيطه لأسبوعين، مثل فرق الدعم والعمليات Operations ومعالجة الطلبات، أو إذا أردت أن تحسن طريقة عمل موجودة دون أن تغير الأدوار. ولا يوجد ما يمنع أن تجمع بينهما، فكثير من فرق Scrum تضع حدوداً للعمل الجاري على لوحة السبرنت وتتابع زمن الإنجاز، وهذا ما وصفه Corey Ladas سنة 2009 باسم Scrumban كما يذكر [مسرد Agile Alliance](https://www.agilealliance.org/glossary/kanban/?ref=arabroot.io). ## ممارسات XP التقنية Engineering Practices التي تنساها أغلب الفرق في سنة 2018 قال Martin Fowler في [محاضرته عن حال Agile](https://martinfowler.com/articles/agile-aus-2018.html?ref=arabroot.io) إن كثيراً من الفرق والمؤتمرات أهملت الجانب التقني مثل إعادة الهيكلة Refactoring والاختبارات الآلية Automated Tests والتكامل المستمر، وإن الفريق دون هذه الممارسات لا يستطيع أن يغير برنامجه بسرعة كما تعده Agile. وهذا منطقي، فالفريق الذي يسلم كل أسبوعين دون اختبارات آلية سوف يقضي السبرنت الثالث في إصلاح ما كسره في الأولين. والممارسات كما يعدها Ron Jeffries في [What is Extreme Programming](https://ronjeffries.com/xprog/what-is-extreme-programming/?ref=arabroot.io) ثلاث عشرة، ونجمعها هنا في ثلاث مجموعات: - **مع العميل:** الفريق الكامل Whole Team الذي يكون فيه من يمثل العميل، ولعبة التخطيط Planning Game، واختبارات العميل Customer Tests أي اختبارات القبول التي تثبت أن الميزة تعمل كما طلبها، والإصدارات الصغيرة Small Releases. - **في الكود:** التصميم البسيط Simple Design، والبرمجة الثنائية Pair Programming، والتطوير بالاختبار أولاً Test-Driven Development، وتحسين التصميم Refactoring، ومعيار كتابة موحد Coding Standard، واستعارة Metaphor تشرح النظام بلغة يفهمها الجميع. - **في الفريق:** التكامل المستمر Continuous Integration، والملكية الجماعية للكود Collective Code Ownership، والوتيرة التي يمكن الاستمرار عليها Sustainable Pace. وأغلب هذه الممارسات لها مقالات عندنا: التكامل المستمر والفروع القصيرة في [Trunk-Based Development](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%81%D8%B1%D8%B9-%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A-trunk-based/)، والاختبارات في [أنواع الاختبارات](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/)، والإصدارات الصغيرة وطرق النشر في [طرق نشر التطبيقات من FTP إلى GitOps](https://arabroot.io/articles/%D8%B7%D8%B1%D9%82-%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%85%D9%86-ftp-%D8%A7%D9%84%D9%89-gitops/). ## التقدير Estimation بنقاط القصة Story Points والسرعة Velocity و#NoEstimates نقاط القصة Story Points طريقة تقدير نسبية، فبدل أن تقول إن العنصر يحتاج إلى ثلاثة أيام تقول إنه ضعف العنصر الذي قدرناه بثلاث نقاط، والسرعة Velocity هي مجموع نقاط العناصر التي انتهت في السبرنت. والفكرة في أصلها مفيدة للفريق نفسه عند التخطيط، فإذا كان متوسط الفريق في آخر خمسة سبرنتات ثلاثين نقطة فلن يختار ستين في السبرنت القادم. ولاحظ أن دليل Scrum لا يذكر النقاط ولا السرعة إطلاقاً، وإنما يقول إن هناك طرقاً للتوقع مثل منحنيات Burn-down وBurn-up، وإنها مفيدة ولكنها لا تغني عن التجربة الفعلية Empiricism، لأن المستقبل في العمل المعقد غير معروف. والمشكلة أن النقاط تحولت في شركات كثيرة إلى أداة رقابة، حتى إن Ron Jeffries، الذي يقال إنه من أوائل من استخدموها، كتب في [مقاله سنة 2019](https://ronjeffries.com/articles/019-01ff/story-points/Index.html?ref=arabroot.io): > I like to say that I may have invented story points, and if I did, I'm sorry now. والسبب كما يشرح في المقال أن المؤسسات صارت تقارن الفرق بالنقاط، وتقارن التقدير بالفعلي بدل أن تركز على القيمة، وتستخدمها للضغط من أجل «المزيد»، فيضحي الفريق بالاختبارات وجودة الكود، فتكثر الأخطاء ويصبح العمل أبطأ. ومن هنا ظهرت حركة **#NoEstimates** التي كان من أبرز من دعوا إليها Woody Zuill وNeil Killick كما يذكر Ron Jeffries في [مقاله عنها سنة 2013](https://ronjeffries.com/xprog/articles/the-noestimates-movement/?ref=arabroot.io)، والفكرة ليست أن تتوقف عن التوقع، وإنما أن تقسم العمل إلى عناصر صغيرة متقاربة الحجم، ثم تتوقع بعدد العناصر والإنتاجية الفعلية Throughput بدل النقاط. فإذا كان الفريق ينهي ستة عناصر في الأسبوع، وبقي في الميزة ثمانية عشر عنصراً، فالتوقع ثلاثة أسابيع تقريباً، وهذا رقم من بيانات حقيقية لا من جلسة تقدير. والحل الأنسب لأغلب الفرق أن تبقي التقدير خفيفاً، وأن تستخدمه للحوار حول حجم العنصر وفهمه، لا كرقم يرفع إلى الإدارة. ## التوسع Scaling لعدة فرق: SAFe وLeSS ونقدهما عندما يعمل عشرة فرق على منتج واحد يظهر سؤال التنسيق، ومن هنا جاءت أطر التوسع Scaling Frameworks، وأشهرها اثنان مختلفان في الفلسفة: - [**SAFe**](https://framework.scaledagile.com/?ref=arabroot.io) **واختصاراً Scaled Agile Framework:** إطار كبير ونسخته الحالية 6.0، ينظم الفرق في قطار إصدار Agile Release Train ويخطط لها معاً في حدث اسمه PI Planning كل فترة تخطيط Planning Interval، وفيه مستويات للحلول الكبيرة والمحافظ Portfolio، وأضاف مؤخراً نسخة باسم AI-Native SAFe. - [**LeSS**](https://less.works/less/framework?ref=arabroot.io) **واختصاراً Large-Scale Scrum:** يحاول أن يبقى أقرب إلى Scrum، فحتى ثمانية فرق، أي نحو 64 شخصاً، يكون هناك مالك منتج واحد، وقائمة منتج واحدة، وتعريف إنجاز واحد، وسبرنت مشترك، وللمنتجات الأكبر نسخة اسمها LeSS Huge. والنقد الموجه لهذه الأطر، وخاصة SAFe، موثق من أشخاص كانوا في قلب Agile نفسها، فقد كتب Ken Schwaber، أحد مؤسسي Scrum، سنة 2013 مقالاً بعنوان [unSAFe at any speed](https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/?ref=arabroot.io) يرى فيه أن SAFe تقدم العمليات والأدوات على الأفراد، أي عكس القيمة الأولى في البيان، وأنها تكرر خطأ الأطر الثقيلة التي تفرض حلاً واحداً للجميع. وفي محاضرة 2018 سمى Martin Fowler هذه الظاهرة [Agile Industrial Complex](https://martinfowler.com/articles/agile-aus-2018.html?ref=arabroot.io)، أي صناعة الاستشارات والشهادات التي تفرض أساليب جاهزة على الفرق، بينما الأصل أن يختار الفريق طريقة عمله. وقبل أن تشتري إطار توسع اسأل نفسك: هل المشكلة أن الفرق تحتاج إلى تنسيق أكثر، أم أن المعمارية تجعل كل فريق ينتظر غيره؟ فإذا كانت الثانية فالحل في [فرق ومعمارية مستقلة Loosely Coupled](https://dora.dev/capabilities/loosely-coupled-teams/?ref=arabroot.io) تستطيع أن تنشر دون أن تنتظر بعضها، لا في اجتماعات تنسيق أكثر. ## أخطاء شائعة تجعل Scrum بالاسم فقط ### Scrum بالاسم فقط يقول دليل Scrum في خاتمته إن تطبيق أجزاء من Scrum ممكن، ولكن النتيجة ليست Scrum. وأوضح مثال على ذلك فريق يعقد كل الأحداث، ولكن لا يوجد Increment يعمل في نهاية السبرنت، ولا مستخدم يراه، ولا قرار يتغير بعد المراجعة. والسبب أن الشركة نقلت الاجتماعات وأبقت القرار والإصدار كما كانا، فالمتطلبات ما زالت تأتي في وثيقة سنوية، والإصدار ما زال كل ثلاثة أشهر. والعلاج أن تسأل في كل مراجعة سؤالاً واحداً: ما الذي تغير في قائمة المنتج بسبب ما رأيناه اليوم؟ فإذا كانت الإجابة «لا شيء» عدة مرات فالمشكلة ليست في الفريق. ### اجتماع يومي Daily Scrum يستمر أربعين دقيقة عندما يتحول الاجتماع اليومي إلى تقرير حالة يقدمه كل شخص للمدير يطول ويفقد غرضه، والسبب أن الحاضرين يتحدثون إلى الشخص الذي يقيمهم لا إلى بعضهم. والدليل حذف الأسئلة الثلاثة في نسخة 2020 لهذا السبب، فالمطلوب خمس عشرة دقيقة حول هدف السبرنت والعوائق، ومن يحتاج إلى نقاش تقني يكمله بعد الاجتماع. ولا تقم بتمديد الاجتماع لأن أحدهم يريد أن يشرح مشكلته بالتفصيل، والسبب أن ستة أشخاص يستمعون إلى نقاش لا يعنيهم. ### سبرنت هو شلال صغير Mini Waterfall الأسبوع الأول للتصميم، والثاني للكود، والاختبار Testing في السبرنت التالي، وهذا هو الشلال نفسه ولكن بمدة أقصر، ونتيجته أن لا شيء ينتهي فعلاً في أي سبرنت. والعلاج أن تقسم العناصر إلى أجزاء صغيرة بحيث يمر كل جزء بالتصميم والكود والاختبار في يومين أو ثلاثة، وأن يكون الاختبار جزءاً من تعريف الإنجاز، وأن يعمل من يختبر مع من يكتب الكود من اليوم الأول. ### السرعة Velocity كمقياس أداء عندما تقارن الإدارة الفرق بالنقاط، أو تطلب زيادة السرعة كل ربع سنة، فإن الفرق تتعلم سريعاً أن تضخم التقدير، فيرتفع الرقم ولا يتغير شيء في المنتج. والسبب أن النقاط وحدة داخلية لكل فريق، فثلاث نقاط عند فريق لا تساوي ثلاثاً عند غيره. ولا تقم برفع السرعة إلى الإدارة كمؤشر أداء KPI، وإنما ارفع ما يهمها فعلاً: ما الذي وصل إلى المستخدمين، وكم استغرق، وكم مرة فشل. ### لا يوجد تعريف للإنجاز Definition of Done بدون تعريف مكتوب يصبح «تم» رأياً شخصياً، فتتراكم الأعمال «شبه المنتهية» وتظهر الأخطاء في الإنتاج بعد أسابيع. والعلاج هو التعريف الذي شرحناه في [تعريف الإنجاز](#definition-of-done)، مكتوباً ومعلقاً بجانب اللوحة، ومراجعاً في كل Retrospective. ### أخطاء أخرى نراها كثيراً - **مالك منتج Product Owner بلا صلاحية:** شخص ينقل الطلبات من الإدارة ولا يستطيع أن يقول «لا» أو أن يغير الترتيب، والدليل يقول إن المؤسسة كلها يجب أن تحترم قراراته. - **استعادة Retrospective دون إجراء:** نفس الشكاوى كل سبرنت ولا شيء يتغير، والعلاج إجراء واحد صغير يوضع في قائمة السبرنت التالي ويراجع في الاستعادة التي بعدها. - **إضافة عناصر في منتصف السبرنت دون تفاوض:** كل طلب عاجل يدخل مباشرة، فيضيع الهدف، والصحيح أن يمر عبر مالك المنتج، وأن يخرج مقابله عنصر آخر إذا لم يمس الهدف. - **لوحة لا تعكس الواقع:** عمل يحدث خارج الأداة في المحادثات والبريد، فلا تكشف اللوحة شيئاً، والقاعدة أن كل عمل يأخذ أكثر من ساعة له بطاقة. ## ما الذي تقيسه بدل عدد النقاط Story Points؟ المقاييس التي تهم المؤسسة هي التي تقيس وصول البرنامج إلى المستخدمين واستقراره، وأشهرها مقاييس [DORA](https://dora.dev/guides/dora-metrics/?ref=arabroot.io) التي تقيس زمن وصول التغيير إلى الإنتاج Lead Time for Changes وتكرار النشر Deployment Frequency ونسبة فشل التغييرات Change Failure Rate وزمن التعافي Recovery Time، وقد شرحنا كيف تستخدمها كمؤشر للفريق لا للأفراد في [خارطة CTO لشركة SaaS ناشئة](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/#ci-cd). ومعها مقاييس التدفق الأربعة من اللوحة نفسها، أي العمل الجاري والإنتاجية وعمر العنصر وزمن الإنجاز، ونسبة السبرنتات التي حققت هدفها Sprint Goal، وأخيراً ما يحدث للمستخدم بعد الإصدار: هل قلت تذاكر الدعم في مثالنا عن كلمة المرور؟ فهذا هو المقياس الذي جاء السبرنت من أجله. ## أدوات مفتوحة المصدر Open Source لإدارة عمل الفريق الأداة لا تجعل الفريق Agile، ولكن الأداة المناسبة تجعل العمل مرئياً للجميع، ولأن بيانات المشاريع وخططها من البيانات التي تفضل كثير من المؤسسات أن تبقى لديها، فهذه أشهر الأدوات مفتوحة المصدر التي تشغلها على سيرفرك، وقد تحققنا من رخصة كل منها في مستودعها الرسمي: | الأداة | الرخصة License | Scrum | Kanban | الحالة | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------- | | [Taiga](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-taiga-%D9%84%D8%A5%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9/) | [MPL-2.0](https://github.com/taigaio/taiga-back/blob/main/LICENSE?ref=arabroot.io) | Backlog وسبرنتات ونقاط وBurndown | نعم | الإصدار 6 في مرحلة صيانة، وله دليل تثبيت عندنا | | [OpenProject](https://www.openproject.org/docs/user-guide/backlogs-scrum/?ref=arabroot.io) | GPL-3.0 | Backlogs وسبرنتات وBurndown في النسخة المجانية Community | لوحات Boards | نشطة، وبعض الميزات مثل مشاركة السبرنت بين المشاريع في النسخة التجارية | | [Plane](https://github.com/makeplane/plane?ref=arabroot.io) | AGPL-3.0 | الدورات Cycles بدل السبرنتات مع Burn-down | نعم | نشطة، ونسخة Community للاستضافة الذاتية | | [Redmine](https://www.redmine.org/?ref=arabroot.io) | GPL-2.0 | لا يذكرها ضمن ميزاته الأساسية | لا يذكرها ضمن ميزاته الأساسية | نشط وقديم ومستقر، قوي في تتبع المشكلات Issues وGantt | | [Kanboard](https://github.com/kanboard/kanboard?ref=arabroot.io) | MIT | لا | نعم، وهو مخصص لها | في وضع صيانة Maintenance Mode بحسب ملف README، أي إصلاحات صغيرة دون ميزات كبيرة | وقد يتساءل البعض: أي أداة أختار؟ والإجابة أن الفريق الصغير الذي يريد Scrum وKanban بواجهة بسيطة يبدأ بTaiga أو Plane، والمؤسسة التي تحتاج إلى Gantt وإدارة محافظ مع Scrum تنظر إلى OpenProject، والفريق الذي يريد لوحة Kanban خفيفة جداً يكفيه Kanboard مع العلم بأنه لا يحصل على ميزات جديدة. وعلى أي حال فلا تختر الأداة قبل أن تتفق على طريقة العمل، والسبب أن الأداة سوف تفرض عليك طريقتها إذا لم تكن لديك طريقة. ## قائمة تحقق لفريق يبدأ أو يعيد البداية - هل يوجد هدف منتج مكتوب في سطرين يعرفه كل الفريق؟ - هل لكل سبرنت هدف واحد، أم قائمة مهام فقط؟ - هل تعريف الإنجاز مكتوب، ويشمل الاختبار والمراجعة والفحص الأمني والنشر على staging؟ - هل يرى مستخدم حقيقي أو من يمثله ما بنيتموه في كل مراجعة؟ - هل الاجتماع اليومي خمس عشرة دقيقة فعلاً؟ - هل على اللوحة حدود للعمل الجاري WIP Limits، خاصة في عمود المراجعة Review؟ - هل تبقى النقاط والسرعة داخل الفريق، وترفع إلى الإدارة مقاييس الوصول إلى المستخدم؟ - هل خرج من آخر استعادة إجراء واحد على الأقل، وهل نفذ؟ ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - Royce لم يخترع الشلال، بل كتب سنة 1970 أن التنفيذ في مسار واحد «risky and invites failure»، والفكرة التي تجمع كل الأساليب بعده أن التعلم المتأخر هو أغلى ما في المشروع. - بيان Agile أربع قيم واثنا عشر مبدأ، ولا يذكر الاجتماعات ولا النقاط، والأشياء التي على اليمين، مثل التوثيق والخطة، لها قيمة ولكنها أقل أولوية عند التعارض. - Scrum في دليل 2020 فريق واحد بثلاث مسؤوليات وخمسة أحداث وثلاثة مخرجات، ولكل مخرج التزام: هدف المنتج وهدف السبرنت وتعريف الإنجاز. - Kanban تبدأ من طريقة عملك الحالية، وتجعلها مرئية، وتحد العمل الجاري، وقانون Little يبين أن بدء أعمال أكثر يطيل الانتظار ولا يزيد الإنجاز. - دون ممارسات XP التقنية، أي الاختبارات والتكامل المستمر وإعادة الهيكلة، لا يستطيع الفريق أن يسلم كل أسبوعين دون أن يكسر ما بناه. - النقاط أداة حوار وتخطيط للفريق، وتحويلها إلى مقياس أداء يفسدها، والتوقع من عدد العناصر والإنتاجية الفعلية بديل يستحق التجربة. - قس ما يصل إلى المستخدم وما يستقر في الإنتاج، واختر الأداة بعد أن تتفق على طريقة العمل لا قبلها. [![](https://arabroot.io/content/images/2026/10/agile-ai-cover-cover.webp)دليلAgile في عصر الذكاء الاصطناعي: ما الذي تغير فعلاً؟ما الذي تقوله الأبحاث عن الذكاء الاصطناعي في فرق البرمجيات، وكيف تعدل طريقة عمل فريقك في Scrum وKanban دون أن تخسر الجودة.](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/)[![](https://arabroot.io/content/images/2026/10/taiga-cover-cover.webp)دليلتثبيت Taiga لإدارة المشاريع بأسلوب Scrum وKanbanكيف تشغل Taiga على سيرفرك لتدير مهام فريقك بأسلوب Scrum أو Kanban بدل جداول Excel والأدوات السحابية.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-taiga-%D9%84%D8%A5%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9/)[![](https://arabroot.io/content/images/2026/10/trunk-based-cover-cover.webp)دليلTrunk-Based Development: فروع قصيرة ودمج يوميلماذا تنفجر الفروع الطويلة يوم الإصدار، وكيف يدمج الفريق عمله في main كل يوم بأمان مع CI وFeature Flags.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%81%D8%B1%D8%B9-%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A-trunk-based/)[![](https://arabroot.io/content/images/2026/10/requirements-practice-cover-cover.webp)دليلمن فكرة غامضة إلى متطلبات Requirements واضحة: مثال عملي مع القوالبكيف تحول جملة «نبغى نظام حجز مواعيد لعيادة» إلى متطلبات Requirements واضحة يمكن بناؤها واختبارها، مع قوالب جاهزة للنسخ.](https://arabroot.io/articles/%D9%85%D9%86-%D9%81%D9%83%D8%B1%D8%A9-%D8%BA%D8%A7%D9%85%D8%B6%D8%A9-%D8%A7%D9%84%D9%89-%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D9%88%D8%A7%D8%B6%D8%AD%D8%A9-%D9%85%D8%AB%D8%A7%D9%84-%D8%B9%D9%85%D9%84%D9%8A/)[![](https://arabroot.io/content/images/2026/10/testing-types-cover-cover.webp)دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/)[![](https://arabroot.io/content/images/2026/10/saas-cto-blueprint-cover-cover.webp)دليلخارطة CTO لشركة SaaS ناشئة من اليوم الأول إلى خمسين موظفاًماذا يجهز المدير التقني في كل مرحلة من نمو شركة SaaS ناشئة، وما الذي يؤجله حتى يحتاجه فعلاً.](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال من المصادر الأصلية: ورقة Royce 1970، وبيان Agile، ودليل Scrum 2020، ودليل Kanban v2025.5، مع رسومات للخط الزمني ودورة Scrum ولوحة Kanban ومثال السبرنت.