إدارة عملية سكروم - نصائح ومزالق وأفكار [مغلق]

Question

لقد قمت بعمل سكروم مع فريق لفترة من الوقت، لكن الأمور تبدو فوضوية لبعض الأسباب.لقد كنت أفكر في كيفية تغييرها ولدي بعض الأسئلة التي أود طرحها هنا.

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

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

ما رأيك يا رفاق في تطبيقه في سيناريوهات أكثر تحديدًا وتعقيدًا؟هل لديك أي خبرة للمشاركة؟

Answer 1

بشكل عام، يعتبر المختبرون والموثقون (وغيرهم من غير المطورين) أعضاء متساوين في فريق سكروم.الفكرة وراء ذلك هي تقليل المخاطر.

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

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

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

الجواب هو الأتمتة، أي أن SCRUM يتواجد دائمًا فوق XP أو Agile، وكلاهما يتطلب تغطية ممتازة لاختبار الوحدة وTDD.وهنا مسكتك أخرى يجب الانتباه إليها.يجب أن يكون مطورو الميزات هم من يكتبون اختبار الوحدة والنظام.يجب أن تتم جميع أتمتة الاختبار بواسطة مطور الميزات.فريق.تم تقسيم بعض الأماكن إلى ميزة التطوير.من تطوير الأتمتة.وهذا سيء.

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

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

في تجربتي، يعد الانتقال إلى Scrum/Agile عملية مؤلمة ومرهقة للغاية وتفشل معظم محاولات الانتقال.أحد مفاتيح النجاح هو وجود بطل Scrum/Agile في الفريق التنفيذي.من وصفك يبدو أنك لا تملك واحدة.

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

Answer 2

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

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

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

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

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

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

Answer 3

لا يجب عليك حقًا إضافة تغييرات إلى قائمة Sprint بناءً على التغييرات التي تم إجراؤها في منتصف Sprint، بل يجب أن تدخل فقط في قائمة Product backlog ويتم تجاهلها حتى انتهاء Sprint.

يجب عليك مواءمة المواعيد النهائية الخاصة بك مع سباقات السرعة.أعتقد أنه من المقبول التراجع عن مهمة في منتصف سباق Sprint، ولكن ليس تقديم مهمة جديدة.

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

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

يمكن للمختبرين، إذا كانوا يعملون على مقربة من المطورين، المساعدة في تحديد ما إذا كان أحد عناصر العمل مكتملًا بالفعل!

Answer 4

أولًا، أنت لا تستخدم Scrum على الإطلاق، ربما تستخدم بعض ممارسات Scrum، ولكن ليس العملية برمتها.

عادةً ما يعمل المصممون والمختبرون على مهمة ما بعد الانتهاء من التطوير، لذا لا يمكنهم التخطيط بشكل مناسب لسباق سريع بسبب هذه التبعية.

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

النتيجة النهائية هي تغييرات متراكمة في منتصف السباق بسبب تغييرات الموعد النهائي، أو نتائج سيئة في نهاية السباق.

يبدو أن طول العدو الخاص بك أوسع مما تحتاج إليه.لماذا لا تحاول أن تجعلها أقصر.طول الركض الجيد هو الطول الذي يمكنك الالتزام به لإبعاد التغييرات عن الركض.أعتقد أن أسبوع واحد سيعمل.

ويوضح هذا السلوك أن Scrum Master الخاص بك لا يقوم بعمله بشكل صحيح لأنه لا يقوم بإزالة العوائق.