الأنماط المضادة للتخطيط السريع – إنشاء المهام – إنشاء المهام

غالبًا ما نرى فرقًا تنشئ مهام لعناصر المنتج المتراكمة أثناء التخطيط لسباق السرعة، ولكن هذه المهام هي مهام قائمة على المهارات مثل الترميز والاختبار والتوثيق وما إلى ذلك. هل هذه هي الطريقة الصحيحة للقيام بذلك؟
ما الخطأ الذي يمكن أن يحدث إذا واصلنا إنشاء المهام بهذه الطريقة؟
كنت في اجتماع مع أحد الفرق، وطرح أحد أعضاء الفريق سؤالاً يتعلق بالسكروم اليومي.
كان السؤال – لماذا لدينا سكروم يومي؟
نعلم جميعًا أن سكروم اليومي هو حدث مهم للتفتيش والتكيف ولكن ماذا لو لم يجده الفريق مفيدًا؟ لماذا لم يكن مفيدًا لهم؟
بدأنا بمراجعة العملية بأكملها ووجدنا أن التخطيط للسباق السريع هو السبب الحقيقي.
شاركنا الفريق في تخطيط العدو السريع الخاص بهم، والذي كان على النحو التالي:-
عناصر المنتج المتراكمة للسباق الحالي – أتمتة فتح صفحة الاستثمار للوكلاء بناءً على نوع العميل مع تفاصيل العميل الأساسية. إنشاء عرض واحد لجميع الاستثمارات لعميل معين بناءً على معرف العميل. أتمتة فتح صفحة القروض للوكلاء بناءً على نوع العميل مع تفاصيل العميل الأساسية. إنشاء عرض واحد لجميع القروض لعميل معين بناءً على معرف العميل.
لوحة المهام
ما الذي يحدث هنا؟ يتم تقسيم الفريق داخليًا إلى أجزاء متعددة للاهتمام بعملهم بناءً على المهارات، وليس النظر إلى القصة بأكملها. كان الجميع يظهر سلوك الشلال (المتسلسل). لم يكن أي من أعضاء الفريق مهتمًا بسماع الأجزاء الأخرى من العمل. نظرًا لأن Daily Scrum مخصص للفريق والفريق غير مهتم بعمل بعضهم البعض، فلماذا لديهم سكروم يومي؟ استمر التخطيط للسباق السريع لمدة ساعة واحدة لمدة أسبوعين لسباق السرعة لأنهم كانوا يعرفون القصص، كما قاموا بتنقيحها خلال PBR. السرعة معروفة جيدًا، لذلك كان الفريق يلتقط العناصر من تراكمات المنتج المطلوبة. نظرًا لأن الفريق يقوم بإنشاء مهمة قائمة على المهارات، فإن المهام عادةً ما تظل هي نفسها لجميع PBIs، لذلك لم يستغرق الأمر الكثير من الوقت. كان الفريق يرفق تلك المهام القياسية لكل PBIs. تم ذلك في 30 دقيقة! لم يناقش الفريق التصميم والبنية أثناء التخطيط؛ وإلا كان من الممكن أن تكون تلك المهام مرئية على متن الطائرة. النتيجة؟ تكرار التعليمات البرمجية لتجنب التبعيات على بعضها البعض، ولكن من يهتم بالديون التقنية ورائحة التعليمات البرمجية؟ كانت هناك العديد من المشكلات الأخرى المتعلقة بسوء التخطيط، مثل تأخر التغذية الراجعة، وحجم الدفعة الأكبر وسير العمل الخانق، وما إلى ذلك. سأشاركها في وقت ما خلال المناقشة وجهاً لوجه. لقد كان هدف “سبرنت” مفقوداً!
ما الذي يمكننا فعله لتجنب مثل هذه المشاكل؟
الأهم من ذلك، الالتزام بالهدف السريع، وليس بالخطة. فحص خطة العدو السريع وتكييفها يومياً مع تقدم العمل. عدم إنشاء مهام قائمة على المهارات. قد يكون من الأفضل عدم إنشاء مهام على الإطلاق ولكن لا تزال هناك حاجة إليها بدلاً من المهام القائمة على المكوّنات مثل الواجهة الأمامية والخدمة والتكامل وما إلى ذلك. تجنب أدوات مثل Jira للتخطيط للسباق السريع واستخدم لوحة فعلية أو لوحة على الإنترنت لتصور وتيسير تعاون الفريق. يجب أن تظهر المهمة أثناء مناقشة النهج والتصميم بدلاً من التخطيط المسبق. يجب أن يكون نهج الفريق بأكمله بحاجة إلى ملكية جماعية. يجب أن يكون التركيز على إكمال مهمة واحدة من مهام تنفيذ المشروع في كل مرة. إذا شعر الفريق أنه لا يوجد عمل كافٍ للجميع حتى يتمكن الفريق بأكمله من إكمال تنفيذ PBI واحد، فابدأ في تنفيذ PBI التالي. التكامل المتكرر للرمز ضروري لتقليل الديون التقنية. حجم دفعات أصغر للحفاظ على التدفق وتحسين حلقة التغذية الراجعة
اشترك في النشرة الإخبارية لسبوتو
ابق على اطلاع على أحدث اتجاهات Agile & Scrum.
نافين كومار سينغ
نافين مدرب أجايل محترف ويعمل بشكل مستقل منذ فترة طويلة في منطقة آسيا والمحيط الهادئ. وهو يعمل مع فريق تطوير البرمجيات وفريق المنتج لتطوير منتجات رائعة بناءً على عمليات تجريبية.