البرمجيات العاملة أهم من التوثيق الشامل: القيمة الثانية في بيان أجايل
قد ينجح فريق المشروع في إعداد عشرات الوثائق والمخططات والتقارير، ثم يكتشف عند موعد التسليم أن المنتج لا يعمل كما يحتاج العميل. في هذه الحالة، لا تعوض جودة التوثيق غياب القيمة الفعلية؛ لأن العميل استثمر للحصول على منتج قابل للاستخدام، لا على ملفات تشرح منتجًا لم يكتمل.
من هنا جاءت القيمة الثانية في بيان أجايل: «البرمجيات العاملة أهم من التوثيق الشامل»، أو بالإنجليزية: Working Software over Comprehensive Documentation. توجه هذه القيمة اهتمام الفريق نحو إنتاج برمجيات تعمل وتحقق حاجة المستخدم، مع الاحتفاظ بالتوثيق الذي يدعم التطوير والتشغيل والصيانة والامتثال.
لا تدعو أجايل إلى إلغاء التوثيق، كما أنها لا تطلب من الفريق البدء في البرمجة دون فهم المتطلبات. بل تعني أن الفريق يمنح القيمة الموجودة في الجانب الأيسر أولوية أعلى، مع اعترافه بقيمة الجانب الأيمن. لذلك تكمن المهارة في إعداد التوثيق الكافي والمفيد، بدلًا من إنتاج وثائق كثيرة لا يستخدمها أحد.
هل هي قيمة أم مبدأ من مبادئ أجايل؟
يمثل هذا النص القيمة الثانية من القيم الأربع الواردة في بيان أجايل، وليس المبدأ الثاني من المبادئ الاثني عشر الملحقة به. ويمثل التفريق بين القيم والمبادئ أمرًا مهمًا؛ فالقيم الأربع تحدد الأولويات العامة، بينما تشرح المبادئ الاثنا عشر طريقة تطبيق التفكير الرشيق في تطوير البرمجيات.
كما يتحدث النص الأصلي عن «البرمجيات العاملة» لأن مطوري برمجيات صاغوا البيان عام 2001. ويمكن للمنظمات استلهام الفكرة في مجالات أخرى عن طريق تقديم مخرج قابل للاستخدام أو نتيجة قابلة للتحقق مبكرًا. ومع ذلك، يظل هذا الاستخدام توسعًا تطبيقيًا في معنى القيمة، لأن النص الأصلي يركز على تطوير البرمجيات.
ماذا تعني البرمجيات العاملة؟
لا يكفي أن يعمل البرنامج على جهاز المطور أو أن تظهر واجهته أمام العميل. تعني البرمجيات العاملة زيادة مكتملة تحقق قيمة مفيدة، وتفي بمعايير الجودة المتفق عليها، ويمكن دمجها مع المنتج وفحصها. وقد يصبح الإصدار جاهزًا للاستخدام الفعلي، حتى لو قرر مالك المنتج تأجيل إطلاقه لأسباب تجارية.
في إطار سكرم، يحدد الفريق حالة الاكتمال من خلال تعريف الإنجاز Definition of Done. وقد يشمل التعريف مراجعة الشفرة، ونجاح الاختبارات، واستيفاء متطلبات الأمن، وتحديث التوثيق الضروري. وإذا لم تحقق الزيادة هذا التعريف، فلا يستطيع الفريق اعتبارها جزءًا مكتملًا من المنتج.
ولهذا لا ينبغي قياس التقدم بعدد الساعات أو المهام المفتوحة أو صفحات التوثيق. تقدم البرمجيات العاملة دليلًا أقوى؛ لأنها تسمح للمستخدمين وأصحاب المصلحة بفحص نتيجة حقيقية وتقديم ملاحظات مبنية على تجربة فعلية.
لماذا تتقدم البرمجيات العاملة على التوثيق الشامل؟
إظهار القيمة مبكرًا
عندما ينتج الفريق جزءًا يعمل خلال دورة قصيرة، يستطيع العميل رؤية أثر الاستثمار مبكرًا. كما يمكنه اختبار الوظيفة والتحقق من ملاءمتها لحاجته. أما الوثيقة المفصلة فتصف ما ينوي الفريق بناءه، لكنها لا تثبت أن الحل سيعمل أو أن المستخدم سيتقبله.
تقليل مخاطر بناء المنتج الخطأ
قد تبدو المتطلبات واضحة عند كتابتها، ثم يكتشف المستخدم عند تجربة المنتج أنه يحتاج إلى سلوك مختلف. تساعد الزيادات العاملة على كشف هذا الفرق مبكرًا، وبذلك يستطيع الفريق تعديل الاتجاه قبل استهلاك معظم الميزانية. وكلما تأخر اكتشاف سوء الفهم، ارتفعت تكلفة إعادة العمل.
تسريع التغذية الراجعة
تنتج تجربة البرنامج ملاحظات أكثر دقة من مراجعة وصف نظري طويل. فقد يوافق المستخدم على تصميم عملية في وثيقة، ثم يجدها بطيئة أو معقدة عند الاستخدام. لذلك تقلص أجايل الفترة بين بناء الوظيفة وتجربتها واتخاذ قرار بشأنها.
مواكبة تغير المعرفة والمتطلبات
تتغير بعض الاحتياجات مع اكتشاف الفريق للمنتج والسوق والقيود التقنية. وإذا وثق الفريق كل التفاصيل مبكرًا، فقد يضطر إلى تحديث قدر كبير منها أو التخلص منه. أما التوثيق التدريجي، فيركز على المعرفة التي يحتاجها الفريق في المرحلة الحالية ويحدثها عندما تتضح التفاصيل.
كشف مشكلات التكامل والجودة
قد تنجح المكونات بصورة منفصلة، لكنها تفشل عند دمجها. يدفع التركيز على الزيادات العاملة الفريق إلى الدمج والاختبار بصورة متكررة، وبذلك يكتشف الأخطاء التقنية قبل تراكمها. كما يمنع الفريق من تأجيل الاختبار والتكامل إلى نهاية المشروع.
هل تعني هذه القيمة إلغاء التوثيق؟
لا. يوضح بيان أجايل أن العناصر الموجودة في الجانب الأيمن تحمل قيمة، رغم منح الأولوية للعناصر الموجودة في الجانب الأيسر. ولذلك لا تمثل العبارة تصريحًا بحذف وثائق المتطلبات أو التصميم أو التشغيل. كما أنها لا تبرر كتابة شفرة غامضة أو تجاهل المعرفة التي يحتاجها الفريق مستقبلًا.
يحتاج المنتج إلى توثيق يساعد الأشخاص على استخدامه وتشغيله وصيانته وتطويره. كذلك قد تفرض العقود أو الأنظمة أو متطلبات الأمن وثائق محددة. في هذه الحالات، تصبح الوثيقة جزءًا من التسليم أو معيارًا من معايير الإنجاز، ولا يستطيع الفريق تجاهلها بحجة العمل الرشيق.
المشكلة ليست في التوثيق نفسه، بل في التوثيق الشامل الذي يتجاوز الحاجة أو يتقادم قبل استخدامه أو لا يقرأه أحد. ومن هنا يسأل الفريق: من سيستخدم هذه الوثيقة؟ وما القرار أو المهمة التي تدعمها؟ وما الحد الكافي من التفاصيل؟ وكيف سنحافظ على تحديثها؟
ما التوثيق الذي يحتاجه المشروع الرشيق؟
لا توجد قائمة موحدة تناسب جميع المنتجات. يحدد الفريق الوثائق بناءً على طبيعة المنتج، وحجم المخاطر، وخبرة المستخدمين، ومدة تشغيل النظام، والمتطلبات التنظيمية. ومع ذلك، قد يحتاج المشروع إلى بعض الأنواع التالية:
- رؤية المنتج وأهدافه: توضح المشكلة التي يحلها المنتج والقيمة المتوقعة منه.
- قائمة المنتج: تعرض الأعمال المطلوبة وترتيبها والأهداف المرتبطة بها.
- معايير القبول: توضح الشروط التي يجب أن تحققها الوظيفة حتى يقبلها المسؤول عنها.
- تعريف الإنجاز: يحدد مستوى الجودة المشترك الذي يجب أن تحققه كل زيادة مكتملة.
- قرارات التصميم والمعمارية: تحفظ القرارات المهمة وأسباب اختيارها والبدائل التي درسها الفريق.
- واجهات التكامل: تشرح طريقة تبادل البيانات بين الأنظمة والخدمات.
- دليل التشغيل والدعم: يساعد فرق التشغيل على نشر المنتج ومراقبته واستعادة الخدمة عند التعطل.
- دليل المستخدم: يشرح الوظائف التي يحتاج المستخدم إلى معرفتها دون حشو تقني غير ضروري.
- سجلات الأمن والامتثال: تقدم الأدلة التي تفرضها الأنظمة والسياسات والتدقيق.
قد يستخدم الفريق النصوص والرسوم والمقاطع المرئية والأمثلة والشفرة بدلًا من الاعتماد على مستندات طويلة فقط. فالمعيار الحقيقي لا يتعلق بشكل الوثيقة، وإنما بقدرتها على نقل المعرفة الصحيحة إلى الشخص المناسب عند الحاجة.
التوثيق الكافي بدل التوثيق الأدنى
يفسر بعض الفرق القيمة على أنها دعوة إلى أقل قدر ممكن من التوثيق، وهذا تفسير ناقص. تحتاج أجايل إلى الحد الكافي الذي يخدم المنتج، وقد يكون هذا الحد صغيرًا في تجربة منخفضة المخاطر، بينما يصبح كبيرًا في نظام مصرفي أو طبي أو حكومي.
على سبيل المثال، قد يكفي فريق صغير يعمل على نموذج تجريبي أن يسجل قراراته الأساسية ومعايير القبول وطريقة التشغيل. أما نظام يعالج بيانات حساسة فيحتاج إلى توثيق أمني وتقني وتشغيلي أكثر تفصيلًا، إلى جانب أدلة الامتثال وإدارة الصلاحيات والتعافي من الأعطال.
لذلك لا يقيس الفريق رشاقته بعدد الوثائق التي حذفها. بل يقيس قدرته على تسليم قيمة متكررة مع المحافظة على الجودة واستمرارية المعرفة. فإذا أدى نقص التوثيق إلى اعتماد المنتج على شخص واحد، أو رفع وقت معالجة الأعطال، أو صعّب انضمام موظف جديد، فقد انخفض التوثيق عن المستوى الكافي.
كيف يدير الفريق التوثيق بطريقة رشيقة؟
1. تحديد مستخدم الوثيقة والغرض منها
قبل إعداد أي وثيقة، يحدد الفريق الشخص الذي سيستخدمها والمهمة التي ستساعده على تنفيذها. فإذا لم يجد مستخدمًا واضحًا أو غرضًا عمليًا، فعليه مراجعة الحاجة إليها بدلًا من كتابتها تلقائيًا.
2. توثيق المعرفة عند ظهورها
لا يحتاج الفريق إلى تأجيل التوثيق حتى نهاية المشروع، ولا إلى توثيق تفاصيل لم يكتشفها بعد. الأفضل أن يحدث الوثائق المهمة بالتزامن مع تطوير الوظائف واتخاذ القرارات. وبهذا يقل احتمال نسيان الأسباب أو تعارض الوثيقة مع المنتج.
3. إبقاء الوثائق قريبة من العمل
يضع الفريق الوثائق في موقع يستطيع أعضاؤه الوصول إليه وتحديثه. وفي المشاريع البرمجية، قد يحفظ بعض الوثائق التقنية بجانب الشفرة حتى يراجعها الفريق ضمن عملية التغيير نفسها. كما يحدد مالكًا للوثيقة أو مسؤولية واضحة عن تحديثها.
4. استخدام القوالب المختصرة
تساعد القوالب على توحيد المعلومات، لكن الفريق يجب ألا يحولها إلى غاية. يمكنه حذف الحقول غير المفيدة وإضافة ما يحتاجه القرار. كما يستطيع استخدام سجل قصير للقرار المعماري بدلًا من تقرير طويل لا يعود إليه المطورون.
5. مراجعة التوثيق مع المنتج
يدخل الفريق تحديث الوثائق الضرورية ضمن تعريف الإنجاز أو قائمة التحقق. فإذا غير وظيفة أو واجهة أو إجراء تشغيل، فإنه يحدث الوثيقة المرتبطة في العمل نفسه. وبذلك لا تتحول المراجعة إلى مشروع منفصل بعد تراكم التغييرات.
6. حذف الوثائق المتقادمة أو تمييزها
قد تسبب الوثيقة القديمة ضررًا أكبر من غياب الوثيقة؛ لأنها تمنح القارئ معلومات يظن أنها صحيحة. لذلك يراجع الفريق المحتوى بصورة دورية، ويحذف النسخ المكررة، ويحدد حالة الوثيقة وتاريخ تحديثها عندما يحتاج إلى الاحتفاظ بها.
هل تحل الاختبارات محل التوثيق؟
تعمل الاختبارات الآلية كنوع من المواصفات القابلة للتنفيذ؛ إذ توضح بعض السلوكيات المتوقعة وتكشف أثر التغييرات. ومع ذلك، لا تحل الاختبارات محل جميع أشكال التوثيق. فقد تثبت أن وظيفة معينة تعمل، لكنها لا تشرح دائمًا سبب القرار أو طريقة تشغيل النظام أو ما يحتاجه المستخدم الجديد.
يستخدم الفريق اختبارات الوحدة للتحقق من أجزاء صغيرة من الشفرة، واختبارات التكامل للتحقق من تفاعل المكونات، واختبارات النظام لفحص السلوك الكامل، واختبارات القبول للتحقق من توافق الوظائف مع المعايير المتفق عليها. تدعم هذه الاختبارات جودة البرمجيات العاملة، بينما يكملها التوثيق الموجه للمطورين والمستخدمين وفرق التشغيل.
ومن الأفضل النظر إلى الشفرة والاختبارات والوثائق بوصفها مصادر معرفة متكاملة. فالشفرة تشرح كيفية التنفيذ، والاختبارات تصف سلوكيات متوقعة، بينما توضح الوثائق السياق والقرارات والاستخدام والتشغيل. وعندما يختار الفريق الأداة المناسبة لكل نوع من المعرفة، يقل الهدر وتتحسن قابلية صيانة المنتج.
مثال عملي على تطبيق القيمة الثانية
لنفترض أن فريقًا يطور بوابة إلكترونية لخدمة العملاء. يستطيع الفريق قضاء ثلاثة أشهر في إعداد وثيقة تفصيلية لجميع الوظائف، ثم بدء التطوير بعد اعتمادها. لكن هذه الطريقة تؤخر تجربة المستخدمين، كما ترفع تكلفة تعديل المتطلبات إذا اكتشفوا أن رحلة الخدمة لا تناسبهم.
وفق النهج الرشيق، يحدد الفريق الحد الأدنى من المعرفة اللازمة، ثم يطور خلال دورة قصيرة وظيفة تقديم الطلب ومتابعته. يحدد معايير القبول، ويختبر الوظيفة، ويحدث تعليمات الاستخدام وقرارات التصميم، ثم يعرض الزيادة العاملة على المستخدمين. تكشف التجربة أن العملاء يحتاجون إلى حفظ الطلب قبل إرساله، فيضيف الفريق هذه الوظيفة إلى الأولويات التالية.
بهذا الأسلوب، لم يتخل الفريق عن التوثيق، لكنه لم يوثق تفاصيل وظائف بعيدة قبل التحقق من الحاجة إليها. كما استخدم البرنامج العامل للحصول على معلومات واقعية، ثم حدث الوثائق مع تطور المنتج. والنتيجة هي تقليل إعادة العمل وربط الجهد بقيمة يستطيع العميل اختبارها.
أخطاء شائعة في فهم القيمة
- العمل دون متطلبات واضحة: لا تلغي أجايل الحاجة إلى فهم المشكلة ومعايير القبول.
- اعتبار كل نموذج أولي منتجًا عاملًا: قد يثبت النموذج فكرة، لكنه لا يحقق بالضرورة مستوى الجودة المطلوب للاستخدام.
- تأجيل التوثيق إلى نهاية المشروع: يؤدي ذلك غالبًا إلى فقدان المعرفة وتراكم أعمال غير مكتملة.
- الاعتماد على ذاكرة الفريق: قد يغادر الأفراد أو ينسون أسباب القرارات، بينما يحتاج المنتج إلى صيانة طويلة.
- توثيق كل شيء بالتفصيل نفسه: تختلف أهمية المعلومات ومخاطر فقدانها، ولذلك تحتاج إلى مستويات مختلفة من التوثيق.
- تجاهل الالتزامات النظامية والتعاقدية: قد تمثل بعض الوثائق تسليمات إلزامية أو أدلة تدقيق.
- قياس التقدم بعدد المهام فقط: لا يثبت إغلاق المهام أن المنتج أصبح مفيدًا أو قابلًا للاستخدام.
الخلاصة
تمنح القيمة الثانية في بيان أجايل الأولوية للبرمجيات العاملة لأنها تقدم دليلًا ملموسًا على التقدم وتسمح بالحصول على ملاحظات مبكرة. لكنها لا تلغي التوثيق ولا تقلل من أهميته عندما يدعم الاستخدام أو الصيانة أو التشغيل أو الامتثال.
يحقق الفريق التوازن عندما يسلم زيادات مكتملة بصورة متكررة، ويوثق المعرفة التي يحتاجها أصحاب المصلحة، ويحافظ على تحديثها مع المنتج. وباختصار، لا يحتاج المشروع إلى الاختيار بين منتج يعمل ووثائق نافعة؛ بل يحتاج إلى منتج يعمل وتوثيق يخدمه دون أن يصبح عبئًا عليه.