ساعدني في فهم كيفية عمل ضمان الجودة في Scrum [مغلق]

Question

من الواضح أننا نستخدم منهجية تطوير Scrum.إليك بشكل عام كيف ستسير الأمور:

يتخبط المطورون في محاولة إنجاز مهامهم.بشكل عام، تستغرق المهام معظم سباق السرعة حتى تكتمل.يضايق QA Dev لإصدار شيء يمكنه اختباره، وأخيراً يقوم Dev بإلقاء بعض التعليمات البرمجية التي تجرها الدواب إلى QA قبل يوم أو يومين من انتهاء السباق ويقضي بقية الوقت في إصلاح الأخطاء التي يجدها QA.لا يمكن أبدًا لـ QA إكمال المهام في الوقت المحدد، ونادرًا ما يتم إطلاق السباقات السريعة في الوقت المحدد، ويواجه Dev وQA بضعة أيام بائسة في نهاية السباق.

كيف من المفترض أن يعمل سكروم عندما تشغل مهام التطوير القابلة للإصدار معظم السباق؟

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

(راجع للشغل - هل هذا هو أفضل مكان لوضع هذا أم كان ينبغي أن أضعه في "إجابة"؟)

نقاط للتفكير/التصرف بناءً عليها:

• تحتاج إلى التأكد من أن مهام المطور صغيرة (محببة) قدر الإمكان.
• يجب أن يعتمد طول العدو بشكل مناسب على متوسط ​​طول المهمة (على سبيل المثال:يجب أن يكون العدو السريع بمهام مدتها أسبوع واحد 4 أسابيع على الأقل)
• يحتاج الفريق (بما في ذلك ضمان الجودة) إلى العمل على أن يصبح أكثر دقة في التقدير.
• فكر في القيام بسباق ضمان الجودة المنفصل بالتوازي ولكن بشكل متقطع إذا كان ذلك يعمل بشكل أفضل للفريق
• وحدة التجارب!

Answer 1

رأيي هو أن لديك مشكلة في التقدير.يبدو أن الوقت المناسب لاختبار كل ميزة مفقود، ويتم أخذ جزء البناء فقط في الاعتبار عند التخطيط للسباق.

لا أقول إنها مشكلة سهلة الحل، لأنها أكثر شيوعًا من أي شيء آخر.لكن الأشياء التي يمكن أن تساعد هي:

• ضع في اعتبارك ضمان الجودة كأعضاء في فريق التطوير، وقم بإدراجهم في التخطيط والتقدير للسباق السريع بشكل أوثق.

• لا ينبغي أن تشغل "مهام التطوير القابلة للإصدار" معظم السباق.يجب أن تكون ميزات العمل كاملة.حاول جمع مقاييس حول وقت التطوير مقابل وقت ضمان الجودة لكل نوع من المهام واستخدم تلك المقاييس عند تقدير فترات السرعة المستقبلية.

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

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

ولكن في النهاية، يعد عدم دقة التقدير مشكلة صعبة في إدارة المشروعات والتي تجدها في المشروعات المستندة إلى Agile أو المستندة إلى الشلال.حظ سعيد.

Answer 2

لقد تأخرت قليلاً عن الحفلة هنا ولكن إليك رأيي بناءً على ما كتبته.

الآن، Scrum هي منهجية لإدارة المشاريع، وليست منهجية تطوير.ولكن من المهم، في رأيي، أن تكون هناك عملية تطوير.وبدونها، فإنك تقضي معظم وقتك رد فعل بدلا من البناء.

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

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

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

العودة إلى الجدولة...

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

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

ربما أنت تقضم أكثر مما يمكن إنجازه أثناء العدو.قد يكون هذا هو الحال.لماذا تفعل ذلك؟لتلبية الجدول الزمني؟إذا كان الأمر كذلك، فهذا هو المكان الذي يجب على الإدارة التدخل فيه وحل المشكلة.إذا كنت تعطي رمزًا خاطئًا لـ QA، فتوقع منهم أن يتخلصوا منه مرة أخرى.من الأفضل أن تعطيهم 3 أشياء ناجحة بدلاً من 8 أشياء غير مكتملة.الهدف هو إنتاج مجموعة من الوظائف التي يتم تنفيذها بالكامل في كل تكرار، وليس تجميع مجموعة من الأشياء غير المكتملة.

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

مكون صغير آخر لكتابة كود الاختبار:لقد وجدت نفسي أكثر استرخاءً وأكثر ثقة بكثير في منتجي منذ اعتماد نهج "اكتب الاختبارات أولاً".عندما تنجح جميع اختباراتي، يكون لدي مستوى من الثقة لم يكن من الممكن أن أحصل عليه بدونها.

حظا سعيدا!

Answer 3

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

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

إذن، هذه هي مشكلة تخصيص الموارد، وامتدادي للسؤال - في السيناريو أعلاه، يتوفر لدى ضمان الجودة الوقت لاختبار الميزات المخطط لها للسباق (3 أسابيع من مهام التطوير، مع ترك الأسبوع الأخير لاختبار الميزات التي تم تسليمها أخيرًا).لنفترض أيضًا أن ضمان الجودة بدأ في الحصول على بعض الميزات القابلة للاختبار بعد أسبوع واحد من التطوير - ولكن ماذا عن الأسبوع رقم 1 لضمان الجودة، وماذا عن الأسبوع رقم 4 للتطوير؟

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

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

Answer 4

نأمل أن تقوم بإصلاح ذلك من خلال معالجة عدد أقل من مهام التطوير في كل سباق.مما يؤدي إلى الأسئلة:من يقوم بإعداد أهداف ديف؟لماذا يفشل Dev في تحقيق هذه الأهداف باستمرار؟

إذا لم يحدد المطورون أهدافهم الخاصة، فهذا هو سبب تأخرهم دائمًا.وهذه ليست الطريقة المثالية لممارسة Scrum.هذا مجرد تطوير تدريجي مع نتائج كبيرة ومحددة بالمواعيد النهائية ولا توجد مسؤولية فعلية لأصحاب المصلحة من جانب المطورين.

إذا لم يتمكن المطورون من تحديد أهدافهم الخاصة لأنهم لا يعرفون ما يكفي، فيجب عليهم أن يشاركوا بشكل أكبر في خط الهجوم.

يعتمد سكروم على أربعة مبادئ أساسية، موضحة في بيان أجيل.

1. التفاعلات مهمة - وهذا يعني أن المطورين وضمان الجودة وإدارة المشروع والمستخدمين النهائيين يحتاجون إلى التحدث أكثر والتحدث مع بعضهم البعض.البرمجيات هي عملية ترميز المعرفة بلغة غامضة لأجهزة الكمبيوتر.لتشفير المعرفة، يجب أن يكون لدى المطورين المعرفة.[لماذا تعتقد أننا نسميها "الكود"؟] إن Scrum ليس منهجية "كتابة المواصفات - رمي فوق العارضة".إنه مضاد لـ "كتابة المواصفات - رمي فوق العارضة"

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

3. تعاون العملاء - وهذا يعني أنه يتعين على المطورين العمل مع محللي الأعمال والمستخدمين النهائيين وأصحاب الأعمال وكل من يمكنه مساعدتهم في فهم ما يقومون ببنائه.المواعيد النهائية لا تهم بقدر ما يهم الشيء التالي الذي يتم تسليمه إلى العميل.إذا كان العميل يحتاج إلى X، فهذا هو الشيء ذو الأولوية القصوى الذي يجب على الجميع القيام به.إذا كانت خطة المشروع تنص على إنشاء Y، فهذا يمثل قدرًا كبيرًا من المالاركي.

4. الاستجابة للتغيير - وهذا يعني أنه يمكن للعملاء إعادة ترتيب أولويات السباقات التالية.لا يمكنهم إعادة ترتيب السباق الجاري (هذا جنون) ولكن جميع السباقات التالية مرشحة لتغيير الأولويات.

إذا كان العميل يقود السيارة، فإن المواعيد النهائية تصبح "معالم المشروع" أقل مصطنعة وأكثر "نحتاج إلى X أولاً، ثم Y، وهذا الشيء في القسم Z، لم نعد بحاجة إلى ذلك بعد الآن.والآن بعد أن أصبح لدينا W، أصبحت Z زائدة عن الحاجة."

Answer 5

تنص قواعد Scrum على أن جميع عناصر Sprint يجب أن يتم "اختبارها بالكامل، وميزات قابلة للتنفيذ" في نهاية Sprint حتى يتم اعتبارها كاملة.تنتهي السباقات السريعة دائمًا في الوقت المحدد، ولا يحصل الفريق على رصيد ولا يُسمح له بتقديم أي شيء غير مكتمل في مراجعة Sprint - وهذا يشمل ضمان الجودة.

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

في المرة القادمة، ستراهن أنهم سيختارون عملًا أقل ويكتشفون كيفية نقله إلى ضمان الجودة حتى يمكن الانتهاء منه في الوقت المحدد.

Answer 6

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

أنا أعمل كجزء من "ثلاثي" (اثنين من المطورين الذين يربطون البرنامج + واحد لضمان الجودة) وأشارك في توزيع القصص وتقدير التخطيط للاجتماعات في بداية التكرارات لمدة أسبوعين.كما ذكر adrianh أعلاه، من الضروري أن يسمع مساعدو الجودة أصواتهم في التخطيط الأولي للسباق.قد يكون هذا صعبًا خاصةً إذا كنت تعمل مع مطورين يتمتعون بشخصيات قوية جدًا، ولكن يجب أن يكون موظفو ضمان الجودة حازمين بالمعنى الحقيقي للكلمة (أي:ليس عدوانيًا أو قويًا ولكن يسعى بكل احترام إلى فهم الحقيقة/أمر الشراء والمطورين/الخبراء التقنيين مع جعل أنفسهم مفهومين).أنا أؤيد إنتاج مهام ضمان الجودة أولاً أثناء التخطيط لتشجيع عقلية الاختبار - قد يتعين على ضمان الجودة أن يتقدموا حرفيًا لاعتماد هذا.إنه عكس ما يعتقده الكثير من الناس أن تطوير البرمجيات ناجح ولكنه يؤتي ثماره لعدة أسباب؛

1. QA is heard and not relegated to being asked "so how are you going to test that?" after Devs have said their piece (waterfall mentality).

2. إنه يسمح لضمان الجودة باقتراح أفكار للاختبار والتي تتحقق في نفس الوقت من قابلية اختبار معايير القبول أثناء وجود الحقيقة/أمر الشراء (لقد قلت أنه من الضروري بالنسبة لهم أن يكونوا حاضرين في اجتماع التخطيط، أليس كذلك؟!) لملء أي فجوات في الفهم.

3. إنه يوفر الأساس لنهج قائم على الاختبار - بعد الإعلان عن نهج الاختبار وتكليفه، يمكن للمطورين التفكير في كيفية إنتاج التعليمات البرمجية لاجتياز تلك الاختبارات.

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

وغني عن القول أن هذا يأتي مع بعض التحذيرات بشأن ضمان الجودة؛

1. يجب أن يكونوا مستعدين لتحدي أفكارهم الخاصة بالاختبار من قبل Devs وTruth/PO وللتوصل إلى حل وسط؛لن يكون موقف "شرطة ضمان الجودة" مقبولاً في فريق Agile.

2. يجب أن تحقق مهام ضمان الجودة توازنًا صعبًا بحيث لا تكون مفصلة جدًا أو عامة جدًا (يمكن كتابة المهام على بطاقة لعرضها على "لوحة المبرد" ومناقشتها في الاجتماعات اليومية - يجب نقلها من "قيد التقدم" إلى "قيد التنفيذ" "مكتمل" أثناء التكرار).

3. يحتاج مساعدو الجودة إلى الاستعداد لاجتماعات التخطيط/التقدير.لا تتوقع أن تكون قادرًا على الحضور وإنتاج نهج اختبار من أعلى رأسك لقصص المستخدمين غير المرئية!يبدو أن المطورين قادرون على القيام بذلك لأن مهامهم غالبًا ما تكون أكثر وضوحًا - على سبيل المثال."تغيير الوحدة النمطية x إلى الواجهة مع المكون z" أو "طريقة إعادة البناء y".باعتبارك مسؤول ضمان الجودة، يجب أن تكون على دراية بالوظيفة التي يتم تقديمها/تغييرها قبل التخطيط حتى يتسنى لك معرفة نطاق الاختبار وتقنيات تصميم الاختبار التي قد تطبقها.

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

5. أقول إن الرقم 4 "ضروري تقريبًا" لأنه يمكن أحيانًا تحقيق نفس الشيء بنجاح باستخدام قوائم المراجعة اليدوية (أجرؤ على قول البرامج النصية!) للسلوك المتوقع - والمفتاح هو مشاركة هذا مع المطورين مسبقًا؛استمر في التحدث معهم!

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

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

كما قلت في البداية، ما زلت لا أملك كل الإجابات ولكن آمل أن يقدم ما ورد أعلاه بعض المؤشرات الناتجة عن تجربة صعبة!

Answer 7

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

Answer 8

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

إذا قام المطورون بإصدار تعليمات برمجية بها أخطاء في نهاية السباق، فسألقي نظرة أيضًا على:

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

إحدى الأفكار التي سمعت أنها تدور حولها في الماضي هي استخدام أحد موظفي ضمان الجودة كمشرف على الحفل.سيكونون حاضرين في المواقف اليومية ويمكنهم التعرف على الأمور مع المطورين.يمكنهم معالجة المشكلات المتعلقة بأمر الشراء (بافتراض أن أمر الشراء يمكنه القيام بعمله بشكل مناسب).

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

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

Answer 9

"كيف من المفترض أن تعمل Scrum عندما تأخذ مهام DEV القابلة لإعادة الاسترخاء معظم العدو؟"

كما اكتشفت - إنها لا تعمل بشكل جيد للغاية :-) العملية التي تصفها لا تبدو لي مثل Scrum - أو على الأقل لا تبدو مثل Scrum بشكل جيد.

لست متأكدًا مما وصفته ما إذا كان فريق ضمان الجودة جزءًا من الفريق - أو مجموعة منفصلة.

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

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

سأحاول بعض الأشياء لو كنت أنا:

• احصل على أفراد ضمان الجودة/الاختبار في الفريق إذا لم يكونوا موجودين هناك بالفعل
• قم بإجراء محادثة طويلة مع مالك المنتج والفريق حول ما يمكن اعتباره "تم".يبدو أن بعض المطورين ما زالوا في عقلية ما قبل scrum المتمثلة في "التسليم إلى ضمان الجودة"" == تم إنجازه.
• قم بتقسيم القصص إلى أجزاء أصغر - مما يسهل اكتشاف أخطاء التقدير
• فكر في القيام بسباقات السرعة القصيرة - لأن القليل وفي كثير من الأحيان يكون من الأسهل تتبعها والتعلم منها.

قد تجد هذه أيضًا نصائح حول تخفيف احتراق سكروم مفيد.

Answer 10

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

Answer 11

تقسيم المهام إلى مهام أصغر.

كما يمكن لـ QA إنشاء حالات اختبار ليختبرها Dev.

Answer 12

إحدى الأفكار التي يجب مراعاتها هي جعل ضمان الجودة يعمل في تكرار واحد خلف التطوير الرئيسي.وهذا يعمل بشكل جيد في بيئتنا.

Answer 13

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

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

إذن ماذا يفعل الاختبار الثاني في الأسبوع الأول من السباق؟

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

امل ان يساعد!