تعريف ما تم إنجازه مقابل معايير القبول: دليل كامل

كمدرب محترف في سكروم وماجستير في سكروم، كثيرًا ما أتلقى هذا السؤال – ما الفرق بين تعريف تم ومعايير القبول؟ على الرغم من أن السؤال قد يبدو بسيطًا جدًا بالنسبة للبعض، إلا أنه لا يزال موجودًا، ويظهر بين الحين والآخر على العديد من المنصات، وفي بعض الأحيان يكون نقطة نقاش.
دعني أبدأ بإجابة مختصرة وذكية شاركني بها أحد زملائي في PST، ثم سأتعمق في شرح أكثر عن كل مصطلح.
إجابة مختصرة
تعريف الإنجاز يتعلق ببناء المنتج “الصحيح”، ومعايير القبول تتعلق بتطوير المنتج “الصحيح”.
إجابة طويلة
دعونا نستكشف ما يعنيه بناء المنتج “بشكل صحيح” وتطوير المنتج “الصحيح”. تطوير المنتج (البرمجيات أو غير ذلك) هو عملية خلق القيمة. ومع ذلك، لا تتحقق القيمة إلا عندما يتم توفير المنتج للمستخدمين النهائيين. كيف نعرف أن المنتج الذي نقوم بإنشائه جيد بما يكفي لإتاحته للمستخدمين النهائيين؟ هنا يصبح مفهوم معايير القبول وتعريف الإنجاز عاملين حاسمين.
يأتي مفهوم معايير القبول جنبًا إلى جنب مع قصص المستخدمين من البرمجة القصوى. وعادةً ما تكون قصة المستخدم عبارة عن وصف قصير مكون من 3 أسطر يعبر عن المتطلبات من وجهة نظر العميل.
وللحصول على أي تفاصيل إضافية، يتعاون المطورون مع الشركة (العميل) لفهم المزيد من التفاصيل. خلال هذه المحادثة، يتفقان (المطورون والعملاء) على السلوك المقبول للمتطلبات. يُطلق على هذا التأكيد المتفق عليه لسلوك المتطلبات اسم معايير القبول.
تُعتبر قصة المستخدم مكتملة إذا كانت تفي بمعايير القبول المنصوص عليها لسلوك الوظيفة. يمكن أن يكون هناك واحد أو أكثر من معايير القبول لأي قصة مستخدم.
مثال على قصة المستخدم:
كمستهلك
أريد إضافة منتجات إلى عربة التسوق الخاصة بي.
حتى أتمكن من شرائها
كيف نعرف أن قصة المستخدم هذه مقبولة للشركات؟ ربما يكون أبسط شيء يمكن القيام به هنا هو عرض المنتج في عربة التسوق بعد إضافته.
ولكن هذا وحده قد لا يكون كافيًا لتلبية احتياجات العمل بشكل كامل. يمكن لمعايير القبول أن تتحقق فقط من العنصر المعروض في عربة التسوق. ومع ذلك، قد تكون هناك حاجة إلى المزيد من المعايير.
يمكن للمطورين والعملاء العمل معًا لتحديد الشروط الأخرى لتلبية قصة المستخدم.
من خلال التعاون، يمكنهم تحديد جميع معايير القبول الضرورية. يساعد ذلك على ضمان توافق قصة المستخدم مع توقعات العمل قبل اعتبارها مكتملة.
على سبيل المثال:
معايير القبول:
تظهر المنتجات المضافة في عربة العميل.
يتم تحديث قيمة سلة التسوق لإظهار مجموع جميع المنتجات المضافة.
يمكن للعملاء الآن التحقق من المنتجات.
يتم تفعيل رابط إزالة المنتج في عربة التسوق.
يتم تفعيل رابط تغيير كمية المنتج على عربة التسوق.
يمكن للمطورين الآن استخدام معايير القبول هذه لكتابة اختبارات القبول التلقائية الخاصة بهم، والتي من شأنها التحقق من صحة سلوك المتطلبات.
ولكن هل هذا كافٍ لإطلاق المنتج للمستخدمين النهائيين؟ كيف لنا أن نعرف أن هذه الوظيفة التي تم إنشاؤها حديثًا لن تعطل أي وظيفة موجودة أو تجعل المنتج عرضة للتهديدات الأمنية، أو لن تؤدي إلى انخفاض أدائه؟
تلبية معايير القبول وحدها لا تعني أن القصة جاهزة للإصدار. هناك حاجة إلى إجراء فحوصات أخرى لمنع حدوث انحدارات أو مشاكل أمنية أو مشاكل في الأداء. وهنا يأتي دور “تعريف الإنجاز” – فهو يتوسع في معايير القبول لتأكيد قابلية الإصدار بشكل كامل.
استكشف دور “مسؤول سكروم” في ضمان الالتزام بتعريف الإنجاز. تعرف على كيفية تيسير فهم الفريق والتزامه بمعايير الجودة. اكتشف إتقان Scrum
يساعد تعريف Done على تحديد “DONENENESS” لزيادة المنتج التي نطورها أثناء التكرار أو العدو السريع كفريق. إنه يساعدنا على توضيح جودة زيادة منتجنا.
إذا كانت زيادة المنتج لا تفي بتعريف Done، فهي ليست جاهزة للإصدار للمستخدمين النهائيين. هذا لأنها تفتقر إلى الجودة الكافية. الاختبار ضروري لضمان الجودة. لذلك، يجب أن يكون إكمال جميع الاختبارات المطلوبة جزءًا من تعريف تم.
قد يبدو التعريف النموذجي لـ “تم” كقائمة مرجعية حول جودة المنتج.
مثال
تتم مراجعة الكود.
يتم اختبار الكود يدويًا في بيئات التطوير والاختبار.
يتم دمج جميع التعليمات البرمجية بشكل متكرر.
يتم إجراء اختبار التكامل.
يتم تشغيل فحص SonarQube لتحديد مقاييس التعليمات البرمجية
تتم إعادة الهيكلة.
وبالنسبة للفرق التي بدأت للتو، يمكن أن تكون أولية وبسيطة، على سبيل المثال:
يتم استيفاء جميع معايير القبول.
يتم إجراء الاختبار.
ومع ذلك، غالبًا ما يتضمن إطلاق زيادة المنتج للمستخدمين النهائيين أكثر من مجرد جودة التعليمات البرمجية. يجب النظر في جوانب أخرى أيضًا قبل الإصدار.
على سبيل المثال، في المجالات شديدة التنظيم مثل التمويل أو الرعاية الصحية، من الضروري تلبية متطلبات الامتثال والمتطلبات التنظيمية. ويجب أن تكون هذه الجوانب جزءًا من تعريف الإنجاز.
وبالتالي، فإن تعريف “تم” يتضمن جوانب جودة التعليمات البرمجية ويجب أن يتضمن جميع جوانب جودة المنتج. مثال على تعريف تم يمكن أن يبدو مثل:
تم استيفاء جميع معايير القبول (جودة المنتج).
جميع اختبارات القبول مؤتمتة (جودة الكود).
يتم توفير ملاحظات الإصدار (الحاجة إلى الامتثال لجودة المنتج).
يتبع المطورون نهج التطوير القائم على الاختبار (جودة التعليمات البرمجية).
تتم مراجعات التعليمات البرمجية (جودة التعليمات البرمجية).
مع كل التزام، يتم تنفيذ SonarQube (جودة التعليمات البرمجية).
مع كل التزام، يتم تنفيذ بناء آلي (جودة التعليمات البرمجية).
يتم إنشاء وثائق المستخدم (جودة المنتج).
يتم اتباع دليل الألوان (جودة المنتج).
يتم الحفاظ على اتساق عائلة الخط وحجم الخط (جودة المنتج).
يتم تحديد تعريف ما تم إنجازه مقدمًا، قبل بدء التطوير، ويظل ثابتًا على مدار المشروع. يتوافق مالك المنتج والفريق على تعريف المنجز في وقت مبكر ويعيد النظر فيه بشكل دوري لإبقائه محدثاً.
من ناحية أخرى، يتم إنشاء معايير القبول بشكل تعاوني لكل قصة مستخدم خلال جلسات التخطيط التكراري وتنقيح الأعمال المتراكمة. يقوم مالك المنتج والفريق بمناقشة معايير القبول والاتفاق عليها عند تفصيل القصص للتحضير للسباقات القادمة.
يتم تسجيل معايير القبول مباشرة مع كل قصة مستخدم، بدلاً من تسجيلها في مستند شامل منفصل. قد تتطور هذه المعايير بشكل متكرر مع معرفة المزيد حول كيفية تلبية قصة المستخدم.
تعريف المنجز ومعايير القبول متشابهان في بعض الجوانب ولكنهما يخدمان أغراضاً مختلفة:
أوجه التشابه:
كلاهما يحدد شروط اعتبار العمل مكتملاً
يعززان التوافق على معايير الجودة
تمكين التحقق من صحة العمل من خلال الاختبار
تحفز التعاون في تحديد معايير الإنجاز
تخلق الشفافية في التقدم المحرز
الاختلافات:
تعريف “تم” شامل، وينطبق على جميع الأعمال
معايير القبول خاصة بقصص المستخدمين الفردية
تعريف المنجز محدد مسبقاً ومستقر.
يتم إنشاء معايير القبول في الوقت المناسب لكل قصة على حدة
يركز تعريف المنجز على معايير الجودة عالية المستوى
تحدد معايير القبول السلوكيات الوظيفية التفصيلية
لذا، على الرغم من أن كلاهما يخدمان أغراضًا مختلفة، إلا أنهما يكملان بعضهما البعض لتوفير عمل كامل وعالي الجودة.
تعريف المنجز ومعايير القبول مختلفان، لكنهما يُستخدمان لأغراض تكميلية. يوفر تعريف المنجز معايير شاملة للاكتمال والجودة التي تنطبق على نطاق واسع على جميع الأعمال. تقدم معايير القبول مواصفات مفصلة تنفرد بها كل قصة مستخدم.
ومن خلال التفريق بين هاتين الأداتين، يمكن للفرق ضمان معايير شاملة للعمل المنجز عالي الجودة من الناحيتين الكلية والجزئية. إن الاستفادة من كليهما جنبًا إلى جنب يمكّن المؤسسات من تقديم زيادات عالية القيمة مع أقصى قدر من المواءمة والشفافية والامتثال والجودة المضمنة على مستويات متعددة.
عادةً ما يكون مالك المنتج مسؤولاً عن كتابة معايير القبول. ومع ذلك، باستخدام نهج تعاوني، يمكن كتابة معايير القبول أثناء جلسات التنقيح أو التخطيط مع مالك المنتج وفريق التطوير وأصحاب المصلحة الآخرين.
يمكن تعريف تعريف ما تم إنجازه من قبل فريق التطوير بأكمله، حيث أنهم مسؤولون عن زيادة المنتج. ومع ذلك، يكون لمالك المنتج القول الفصل في محتواه والتغييرات التي تطرأ عليه.
وتتمثل الأغراض الرئيسية لمعايير القبول في تحديد النطاق والمتطلبات، والمساعدة في التقدير، وتمكين الاختبار/ضمان الجودة، والحد من سوء التواصل، ودعم التعاون، وإدارة زحف النطاق.
بعض الأغراض الرئيسية من وجود تعريف للإنجاز في تطوير البرمجيات الرشيقة هي إنشاء فهم مشترك، ووضع معايير الجودة، والحد من عدم اليقين، ووضع إطار للزيادات القابلة للإصدار.
أعمل كمدرب رشيق-أجايل متحمس مع أكثر من 19 عامًا من الخبرة المتنوعة، وأعمل مع المهنيين والفرق والمنظمات لمساعدتهم في سعيهم لتحقيق المرونة. كوني مدرّب محترف في سكروم (Scrum.org)، ومدرب محترف في سكروم (Scrum.org)، ومدرب معتمد من ICAgile.