1. الفلسفة الجوهرية (التنبؤية مقابل التكيفية)

• الشلال (التنبؤي): يفترض أن المشكلة مفهومة بالكامل، والحل واضح، والبيئة المحيطة مستقرة. يعتمد على الاعتقاد بأنه إذا تم التخطيط بدقة مسبقة، فإن التنفيذ سيكون سلساً. يعالج التطوير وكأنه خط تجميع.

• أجايل (التكيفي): يفترض أن المشكلة معقدة، وأن الحل سيتكشف تدريجياً مع الوقت، وأن البيئة المحيطة تتغير باستمرار. يعتمد على النموذج التجريبي، مما يعني أن المعرفة تأتي من التجربة والملاحظة، وليس من التكهنات المسبقة. أنت تبني، وتفحص، وتتكيف في الوقت الفعلي.

2. التخطيط وإدارة النطاق (المجال)

• الشلال: النطاق (المجال) ثابت، بينما الوقت والتكلفة متغيران (أو يتم حسابهما بناءً على ذلك النطاق الثابت). تحدد كل متطلبات المشروع في وثيقة ضخمة (وثيقة متطلبات الأعمال) قبل كتابة سطر واحد من الكود. إذا أردت إضافة ميزة لاحقاً، يجب تقديم "طلب تغيير" رسمي، مما يستلزم غالباً إعادة التفاوض على الميزانية والجدول الزمني.

• أجايل: الوقت والتكلفة ثابتان (على سبيل المثال، ميزانية سباق مدته أسبوعان)، بينما النطاق متغير. بدلاً من تحديد كل شيء مسبقاً، تقوم بإنشاء "قائمة المنتج المتراكمة" (Product Backlog) وهي قائمة أولويات بالميزات المطلوبة. في بداية كل سباق (Sprint)، يسحب الفريق فقط أهم العناصر التي يمكنه إنجازها بواقعية. إذا ظهرت أولويات جديدة، يتم ببساطة استبدال العناصر الأقل أهمية في السباق التالي.

3. تكلفة التغيير (الفرق الأكثر أهمية)

• الشلال: تكلفة إجراء تغيير تزداد بشكل هائل مع مرور الوقت. اكتشاف عيب تصميمي كبير خلال مرحلة "المتطلبات" يكلف بضعة دولارات لإصلاحه. اكتشاف نفس العيب خلال مرحلة "الاختبار" (بعد أشهر من التطوير) يكلف آلاف الدولارات، لأنه يتطلب إعادة كتابة الكود، وإعادة الاختبار، وربما إعادة التوثيق. اكتشافه بعد "النشر" قد يكلف الملايين ويدمر سمعة المنتج.

• أجايل: تكلفة التغيير مسطحة (ثابتة نسبياً). لأنك تبني في دورات قصيرة ومتزايدة (سباقات)، ولأن التطوير الموجه بالاختبارات (TDD) يضمن وجود شبكة أمان قوية، فإن إجراء تحول كبير في الاتجاه في السباق رقم 10 يكلف تقريباً نفس تكلفته في السباق رقم 1. لا يوجد "تكلفة غارقة" تجبرك على الاستمرار في مسار خاطئ.

4. المراحل والتوقيت (التسلسل مقابل التزامن)

• الشلال: هو تسلسلي بشكل صارم. يجب إكمال 100% من تحليل المتطلبات ← ثم 100% من التصميم ← ثم 100% من التطوير ← ثم 100% من الاختبار ← ثم 100% من النشر. لا يوجد تداخل بين المراحل. لا يمكنك البدء في اختبار مكون ما قبل أن يتم بناؤه بالكامل.

• أجايل: هو متزامن ومتكرر (تفاعلي). في سباق واحد مدته أسبوعان، يقوم الفريق بجميع المراحل في وقت واحد: يحللون جزءاً صغيراً، ويصممونه، ويكتبون كوده، ويختبرونه، ويدمجونه مع النظام. بحلول نهاية السباق، لديك إضافة منتج كاملة ومختبرة وقابلة للنشر. لا تنتظر حتى النهاية لترى ما بنيته.

5. التعامل مع الاختبار والجودة

• الشلال: ينظر إلى الاختبار كمرحلة منفصلة تحدث قبل النشر مباشرة. يحصل فريق ضمان الجودة (QA) على البرنامج الكامل فقط في النهاية. هذا يخلق ثقافة "رمي البرنامج على فريق الجودة"، حيث يرمي المطورون الكود لفريق QA. غالباً ما يصبح فريق QA عنق الزجاجة (الاختناق)، حيث يكتشف كميات هائلة من الأخطاء في وقت متأخر جداً.

• أجايل: ينظر إلى الجودة كمسؤولية الجميع، مدمجة منذ البداية. يكتب المطورون اختبارات آلية قبل أو بجانب كتابة كود الإنتاج. يتم دمج مهندسي ضمان الجودة ضمن نفس الفريق متعدد التخصصات ويختبرون الميزات فور الانتهاء من كتابتها (الاختبار المبكر). يتم إصلاح العيوب فوراً، وليس تجميعها في النهاية.

6. مشاركة أصحاب المصلحة والعملاء

• الشلال: أصحاب المصلحة مشاركون بشكل مكثف في البداية (التوقيع على المتطلبات) وفي النهاية (اختبار قبول المستخدم). خلال مرحلة التطوير الطويلة، يكونون عادةً غائبين. عندما يرون المنتج أخيراً بعد 6 أشهر، غالباً ما تكون النتيجة صدمة كبيرة - فهو ليس ما تخيلوه، ولكن الأوان قد فات للتغيير.

• أجايل: أصحاب المصلحة (مالك المنتج) مشاركون بشكل مستمر، كل يوم. يحضرون مراجعات السباق كل أسبوعين لرؤية برنامج حي يعمل. يقدمون ملاحظات فورية. هذا يلغي "عامل الصدمة" في التسليم لأن العميل شاهد المنتج يتطور خطوة بخطوة.

7. ديناميكيات الفريق والأدوار

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

• أجايل: مسطح (غير هرمي)، ذاتي التنظيم، ومتعدد التخصصات. الأدوار هي أخصائيون عامون (على سبيل المثال، مطور يكتب اختبارات أيضاً، أو مهندس جودة يساعد في الأتمتة). يقوم سيد السكرام (Scrum Master) بخدمة الفريق (بدلاً من إصدار الأوامر لهم). يمتلك الفريق التسليم بشكل جماعي، ويقدرون العمل بأنفسهم، ويقررون كيف سيبنون الحل.

8. مقاييس النجاح (المخرجات مقابل النتائج)

• الشلال: يقيس النجاح من خلال "الخطة مقابل التنفيذ". هل التزمنا بمخطط جانت؟ هل سلمنا بالضبط ما هو موجود في الوثيقة المكونة من 200 صفحة؟ النجاح النهائي هو الالتزام بالموعد النهائي والميزانية، حتى لو كانت القيمة التجارية للميزات أصبحت الآن غير ذات صلة بسبب تغيرات السوق.

• أجايل: يقيس النجاح من خلال "القيمة المقدمة". ما هي المشاكل التجارية التي حللناها؟ هل زاد تفاعل المستخدمين أو الإيرادات؟ هل سلمنا العناصر ذات الأولوية القصوى أولاً؟ يتم قياس النجاح من خلال برنامج يعمل ويلبي احتياجات المستخدم الحالية، حتى لو لم نبني كل ما أدرجناه في القائمة في البداية.