Agile أم Waterfall أم Hybrid في مشروع Salesforce؟ اختيار نموذج التسليم

الإجابة المختصرة

الاختيار ليس بين منهجيتين، بل بين نوعين من القرارات. هناك قرارات تزداد تكلفة تغييرها بشكل حاد مع مرور الوقت – مثل نموذج البيانات، والصلاحيات، والتكاملات – ويجب تثبيتها مبكرًا. وهناك قرارات تكون تكلفة تغييرها منخفضة – مثل الشاشات، والحقول، والتقارير، والصياغات – ويفضل اكتشافها تدريجيًا.

لذا، فإن النموذج المتبع في معظم مشاريع Salesforce هو نموذج هجين ليس من باب التسوية ولكن بحكم الهيكلية: إطار عمل ثابت، ومحتوى تكراري.

المتغيرات الثلاثة الحاسمة

المتغير الثاني أكثر أهمية مما هو مفترض. منهجية Agile بدون توفر المستخدمين ليست Agile – إنها سلسلة من السبرنتات التي في نهايتها لم يقم أحد بالمراجعة، وتأتي جميع الملاحظات دفعة واحدة في اختبار قبول المستخدم (UAT).

النموذج الهجين في الممارسة العملية

النهج الفعال يقسم المشروع إلى جزأين بوتيرة مختلفة:

مرحلة الإطار (4-6 أسابيع، تخطيطية) – نموذج البيانات، نموذج الصلاحيات والرؤية، تخطيط التكاملات، استراتيجية ترحيل البيانات، وتحديد العمليات التي ستدخل في الدفعة الأولى. يتم توثيق مخرجات هذه المرحلة والموافقة عليها.

دفعات التسليم (سبرنتات لمدة أسبوعين) – يقدم كل دفعة سيناريو كاملاً لملف تعريف المستخدم، بما في ذلك الاختبار والملاحظات. التغييرات ضمن الدفعة لا تتطلب إعادة موافقة ما دامت لا تمس الإطار العام.

القاعدة التي تحكم ذلك: تغيير في الإطار هو قرار إداري، وتغيير في المحتوى هو عمل مستمر. بدون هذا التمييز، سيصل كل طلب صغير إلى اللجنة التوجيهية، ويمر كل تغيير هيكلي دون رقابة.

أين ينكسر كل نموذج

نموذج Waterfall النقي ينكسر في UAT: الفجوة بين ما كُتب في المستند قبل ستة أشهر وما يتوقعه المستخدم تظهر متأخرة جدًا بحيث لا يمكن إصلاحها بتكلفة منخفضة.

نموذج Agile النقي ينكسر في نموذج البيانات: بعد ستة سبرنتات من القرارات المحلية، يتضح أن الهيكل لا يدعم إعداد التقارير عبر العمليات، ويتطلب الإصلاح ترحيل بيانات.

النموذج الهجين ينكسر عندما لا يتم إغلاق الإطار بشكل فعال – عندما يكون "إطارًا" بالاسم ولكنه يُفتح من جديد في كل دفعة. حينها، نتحمل عيوب كلا النموذجين.

ما يجب قياسه على طول الطريق

تكفي ثلاثة مقاييس لمعرفة ما إذا كان النموذج يعمل: النسبة بين العناصر المكتملة والعناصر التي أعيد فتحها، الوقت المستغرق من تلقي ملاحظات المستخدم حتى الإصلاح، وعدد التغييرات التي مست الإطار. الزيادة في المقياس الثالث هي العلامة المبكرة على أن التخطيط المسبق كان سطحيًا. يمكن الاطلاع على العلاقة بإدارة النطاق في Scope Creep وضبط التغييرات والجداول الزمنية في الجدول الزمني لمشروع Salesforce.

الملخص

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