تعريف جاهز - ما نسينا أن نقول عنه

مقدمة
ما هو DoR
لماذا تحتاج إلى DoR؟
أين تستخدم DoR
متى تستخدم DoR
نموذج INVEST
الخلاصة
المراجع

مقدمة

من المؤكد أنك سمعت أكثر من مرة ، وربما استخدمت حتى قطعة سكروم - تعريف تم مع الفريق ، فيما يلي - DoD. ربما استخدمها دون أن تدرك ذلك. تمت كتابة العديد من المقالات باللغة الروسية حول DoD. يتحدثون عنه في المؤتمرات والدورات التدريبية. إن فهم سبب الحاجة إلى هذه القطعة الأثرية وإيجاد أمثلة ليس بالأمر الصعب. تحدد وزارة الدفاع المعايير التي يفهم من خلالها كل عضو في الفريق أن المهمة مغلقة. الهدف الأعمق هو مزامنة مفهوم Done بين كل عضو في الفريق. فوق هذه المعايير ، غالبًا ما يعمل الفريق أثناء استعادي. هناك قطعة أثرية مماثلة حولها لسبب ما لا يوجد ذكر لـ Scrum في الموارد الناطقة بالروسية ، وحيث يتم ذكر هذه الأداة ، لا يتم إعطاء أي تفسير لما هو ، ولماذا هناك حاجة إليه ، وكيفية استخدامه.

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

تعريف جاهز ، المشار إليه فيما بعد باسم DoR ، عثر عليه بالصدفة في محادثة ملف شخصي مخصصة لأجيل. في محاولة للعثور على معلومات ، لم أجد إشارة واحدة في RuNet حول هذا الموضوع. لذلك ، ذهبت لقراءة وترجمة مقالات باللغة الإنجليزية. الآن أنا أشارك النتيجة معك ، آمل أن يساعد ذلك على جعل فريقك أكثر برودة وإنتاجية.

ما هو DoR

إذن ما هو DoR؟ سيخبرك مترجم جوجل أن هذا هو "تعريف الاستعداد". إذا تضمنت DoD معايير لإكمال مهمة ، فإن DoR - معايير استعداد المهمة التي يجب اتخاذها للعمل. أي أنه إذا استوفت المهمة معايير DoR ، يمكن للفريق أن يأخذها في التخطيط للعمل. يبدو الأمر بسيطًا ، ربما بدأت بالفعل في التفكير في كيفية ، أخيرًا ، مع الفريق ، إعداد قائمة كاملة لمتطلبات أمر الشراء الخاص بك بحيث يبدأ في كتابة الكثير من الوثائق ، وبقية أعضاء الفريق يمكنهم الجلوس بهدوء على أجهزة الكمبيوتر الخاصة بهم وكتابة التعليمات البرمجية بصمت. هذه ليست سوى البداية ، و DoR ليس كما يبدو للوهلة الأولى.

لماذا تحتاج إلى DoR؟

أولاً ، نجيب على السؤال: لماذا هذه القطعة الأثرية مطلوبة؟ ما الفائدة التي سيجلبها للفريق؟ سوف تساعد DoR الفريق على:

1. تجنب بدء العمل على الميزات التي لا تحتوي على تعريف واضح لمعايير الإنجاز. سيفهم الفريق متى تعتبر قصة المستخدم كاملة ، وما يجب القيام به للقيام بذلك.
2. لا تضيع الكثير من الوقت دون جدوى في المناقشات المطولة والمهام غير المدروسة. ستوفر المهمة التي تمت معالجتها مسبقًا وقت الفريق بأكمله. احسب كم من الوقت يستغرق لمناقشة مهمة "سيئة" لشخص واحد. الآن اضرب في عدد الأشخاص في الفريق. والآن لعدد مثل هذه المهام.
3. ركز الوقت والطاقة على الأشياء "الآمنة" قدر الإمكان. واحدة من أقوى المستهدفين هي الوظيفة التي يتم طرحها في سلة المهملات.
4. أشرك كل مشارك في مناقشة المهام. أولاً ، إنه يحفز الفريق. ثانيًا ، من المفيد الكشف عن كل عضو في الفريق كمتخصص. ثالثًا ، سيقدم المطورون رؤيتهم الخاصة للمشكلة. خلال المناقشة ، قد تنشأ حلول أخرى تختلف جذريًا عن الفكرة الأصلية.

دعونا نلقي نظرة على قائمة المشاكل التي تنتج بشكل مباشر أو غير مباشر عن نقص DoR:

1. تظهر الاختلافات في فهم المشكلة بانتظام بين أعضاء الفريق. بحلول نهاية السباق ، يزداد التناقض ، مما يؤدي إلى حوادث تحدث فيها تغييرات في عملية التطوير ، وهو أمر طبيعي. ولكن في ضوء حقيقة أن هذه اللحظات لم يتم تسجيلها ، فإن الشخص الذي واجهها مباشرة يعرف عنها.
2. تتغير المتطلبات الوظيفية بشكل أسرع من تمكن الفريق من فهمها. نظرًا لأن المهمة دخلت العدو ، مع عدم اليقين الشديد ، في الوقت الذي يكون فيه الجزء جاهزًا ووضع "الأساس" ، تظهر معلومات جديدة تتطلب العودة إلى البداية. كلما كانت المهمة أسوأ ، كلما نشأت مثل هذه الحالة في السباق. في النهاية ، سيؤدي هذا إلى fakap.
3. غالبًا ما تكون هناك مشاكل في تقييم النتيجة التي تم الحصول عليها من الوظيفة ، ولا يعرف الفريق كيفية جمع المقاييس ، أو الأسوأ من ذلك ، نسيانها. يتعلق سكروم في المقام الأول بالفوائد التي تعود على العميل أو المستخدم أو المشتري. إذا لم يقم الفريق بتقييم فوائد المهمة ، فلن يتلقى ردود فعل وقدرة على تعديل دورة تطوير المنتج. هذا يمكن أن يؤدي إلى الفشل الكامل.
4. أيضًا ، فإن نقص DoR له تأثير كبير على الاختبار ، وبدلاً من اختبار اختبارات ضمان الجودة في قصة المستخدم ، فإنه سيختبر توقعات المطورين. يمكن أن تعمل الشفرة بشكل مثالي ، وستعمل الاختبارات التلقائية مثل الساعة ، ولكن الوظيفة لن تعمل على الإنتاج.

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

أين تستخدم DoR

تُستخدم DoRs في تحسين المنتج المتراكم المشار إليه فيما يلي باسم PBR أو اسم الأداة الأكثر شيوعًا: Grooming. خلال هذا النشاط ، تصبح قصص المستخدم جاهزة - جاهزة. هذا يعني أن نتيجة الحدث ، في تراكم المنتج ، هي Ready US. هناك حاجة إلى DoR لوصف الحالة التي يمكن فيها مناقشة الولايات المتحدة بشأن التخطيط. هذا يسمى Takin في - مقبولة من الولايات المتحدة.

للمضي قدمًا ، فأنا أهتم بكيفية تحدث جيف ساذرلاند ، أحد مؤسسي بيان سكروم وأجيل ، عن DoR و DoD في مقاطع الفيديو الخاصة به. يقدم ساذرلاند مفاهيم Done-Done و Ready-Ready. عندما يقول أحد أعضاء الفريق أن المهمة جاهزة أو مكتملة ، يُفهم أنها تفي بالمعايير التي حددها الفريق في DoD و DoR ، على التوالي. هذا جانب مهم ، يجب على كل عضو في الفريق فهمه ، وعدم النسيان. خلاف ذلك ، تنشأ مواقف مضحكة عندما يخبر بيتيا في صحيفة Daily أن المهمة قد اكتملت بالفعل ، ثم اتضح أن هناك حاجة إلى إضافة الاختبارات هناك ، وسيكون من الجيد إعادة صياغة الرمز ، ولم يتم مراجعة Code Code حتى الآن.

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

متى تستخدم DoR

عندما يدرك الفريق أثناء PBR أن المهمة لا تتوافق مع DoR ، وتحمل الكثير من عدم اليقين ، قم بعمل قائمة بالأسئلة ، واختر باحثًا ، وقم بتأجيل المهمة حتى PBR التالي. في فريقي ، كان يطلق عليه البحث ، ولكن في وقت لاحق انتقلنا إلى Spike من XP ، لأننا اعتقدنا أنه يجلب المزيد من النتائج والوضوح حول نتائج الدراسة. تأكد من تحديد الدراسة بالوقت ، وحدد النتيجة التي تريد الحصول عليها في النهاية. أثناء سبايك ، يمكن للباحث جذب أي مساعدة من الخارج ، على سبيل المثال ، أعضاء الفرق الأخرى ، المنهجيين ، POs ، المهندسين المعماريين ... بشكل عام ، أي شخص يراه مناسبًا. النتيجة - إجابات للأسئلة والبيانات الجديدة والنموذج الأولي. إذا كان هناك العديد من قصص المستخدم هذه ، يمكنك أخذ 1-2 سبايك في كل سباق للنسخة التالية ، وبالتالي ضمان التدفق المستمر للمهام الجاهزة.

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

تصف العديد من المقالات نموذج INVEST ، الذي يشبه SMART ، ولكنه أكثر ملاءمة لقصة المستخدم. بالإضافة إلى المقالات ، يوصى بهذا النموذج أيضًا في الأدبيات الرشيقة. على سبيل المثال ، رومان بيشلر في كتاب "إدارة المنتجات في سكروم" أو مايك كوهن - "قصص المستخدم. تطوير البرمجيات المرنة ".

نموذج INVEST

• الاستقلال المستقل - حاول تجنب إنشاء الولايات المتحدة التي تعتمد على بعضها البعض ، فهذه التبعيات تسبب مشاكل في تحديد الأولويات والتخطيط. يمكن للعميل اختيار الولايات المتحدة بأولوية عالية ، والتي تعتمد على المهمة بأولوية أقل. يجب دمج الولايات المتحدة التابعة أو تقسيمها بشكل مختلف أو ارتفاعها.
• قابل للتفاوض - الولايات المتحدة ليست التزامًا أو متطلبات تعاقدية رسمية. الولايات المتحدة ليست مهمة فنية. خلال السباق ، يمكن ويجب مناقشتها وتعديلها. البطاقة التي لها تاريخ ، أيا كان شكلها ، هي وصف موجز للوظيفة ، والتي يجب توضيح تفاصيلها أثناء العمل. اترك الملاحظات على البطاقات لتوليد المناقشة عند اكتمال المهمة. من المهم إيجاد حل وسط هنا ، لأن فائض الملاحظات ، سيعتبر الفريق معلومات شاملة ، ولن تكون هناك مناقشة على الإطلاق. جاء فريقي عبر هذا بسرعة كبيرة. تصبح التفاصيل التي نوقشت اختبارات يمكن كتابتها على ظهر الورقة ، أو في التعليق على البطاقة الإلكترونية. اختبارات القبول بسيطة وواضحة للجميع.
• القيمة القيمة للمستخدم أو العميل - "يجب أن يكون لكل قصة قيمة معينة للمستخدم" - عبارة غير صحيحة. في الغالب ينسى المشتري. التركيز ، اعتمادًا على شركتك: B2C ، B2B ، B2G. الشيء الرئيسي هو تجنب القصص ذات القيمة للمطورين فقط. يجب إعادة صياغة هذه القصص بحيث تصبح الفوائد واضحة ويمكن للعميل تحديد الأولويات. لا حاجة لرمي المهام المعمارية في سلة المهملات ، وشرح للعميل الفوائد التي ستجلبها هذه المهمة ، وإعادة صياغتها.
• التقييم التقديري - يجب أن يتمكن المطورون من تقدير حجم الولايات المتحدة ، أي الوقت التقريبي الذي سيستغرقه التنفيذ. هناك ثلاثة أسباب رئيسية لعدم إمكانية قياس كثافة اليد العاملة:
  
  
  1. الفريق يفتقر إلى معرفة الموضوع
  2. الفريق يفتقر إلى الخبرة التقنية
  3. القصة كبيرة جدا
  
  في الحالة الأولى والثانية ، سوف تساعدك سبايك. في الثالثة ، تحتاج الولايات المتحدة إلى أن تتحلل إلى أخرى أصغر.
• الحجم الصغير - يعتمد الكثير على حجم الولايات المتحدة ، ويصعب تقييم الولايات المتحدة الكبيرة جدًا والصغيرة جدًا. من الصعب العمل مع الملاحم ، لأنها تتكون من العديد من الولايات المتحدة. يمكن تقسيم الملاحم إلى نوعين:
  
  
  1. مركب. كل شيء بسيط هنا - نتحلل. ضع في اعتبارك بقية النقاط ، أول شيء سيقترحه الفريق على الأرجح: تقسيم الولايات المتحدة حسب نوع الطبقة المعمارية: من الولايات المتحدة إلى قاعدة بيانات ، الواجهة الخلفية ، الواجهة الأمامية ، وما إلى ذلك.
  2. معقد. يرجع الحجم الكبير للولايات المتحدة إلى جوهرها ، إما أنها غير متحللة ، أو أنها صعبة للغاية. في هذه الحالة ، نستخدم ارتفاعًا.
  
  
• قابلية للاختبار - التأكيد على أن الولايات المتحدة قد تم تطويرها بنجاح ، بمثابة اختبار ناجح. إذا كان لا يمكن اختبار الولايات المتحدة ، فلن يعرف الفريق متى يكتمل الإنشاء ، أو سيخرج بالمعايير نفسها. علاوة على ذلك ، سيكون كل عضو في الفريق مختلفًا.

الخلاصة

في الختام: باستخدام DoR ، لن تتخلص من الفجوات التي ستتسرب إلى العدو. هذا لا يعني أيضًا أنه خلال فترة السباق ليست هناك حاجة للاتصال المستمر بين PO والمطورين. سجل باستمرار نتائج المناقشات في شكل اختبارات القبول ، لذلك لن يفقد أي فريق فهم حالة المهمة. حلل المشاكل الحالية وناقشها مع الفريق ، ربما تتعلق بنقص DoR.
DoR هي قطعة أثرية ستسمح للفريق بالتفكير من خلال الولايات المتحدة بشكل أفضل ، مما سيقلل من المخاطر في نهاية المطاف ، وسيسمح لكل عضو في الفريق بمناقشة المهام باستمرار. ستجد الكثير من المعلومات التفصيلية حول INVEST وقصة المستخدم في كتاب "قصص المستخدم". أوصي بإعطاء كل عضو في الفريق قراءة هذا الكتاب ، أو على الأقل قراءته بنفسك ومشاركة المعلومات معهم.
اكتب في التعليقات التي تستخدم DoD و DoR في فريقك.

المراجع

1) رومان بيشلر "إدارة المنتجات في سكروم"
2) مايك كوهن "قصص مخصصة. تطوير البرمجيات المرنة "
3) agilealliance.org
4) ينكدين
5) boost.co.nz
6) scruminc.com