4 عمليات غير صحية يمكن أن تدمر سباقك السريع
في مقالتي السابقة ، بدأت المناقشة حول العادات السيئة التطور داخل فريق سكرم والتي ستؤدي في النهاية (عاجلاً أم آجلاً) إلى فشل في التسليم. في هذه المقالة ، أود توسيع هذا الموضوع مرة أخرى والتركيز الآن على العمليات الوظيفية داخل الفريق.
تلك هي بنفس أهمية التميز التقني للفريق. حتى لو كان الأشخاص بالداخل يتمتعون بمهارات فائقة في العمل الذي هم على وشك القيام به ، فلا تزال هناك مناطق يمكن أن تدمر جهودهم لتحقيق الكمال. ولن يكون هذا خطأهم إلى هذا الحد حيث ستكون المسؤولية المباشرة لقرارات إدارة المشروع وقدرتهم على خدمة الفريق بعمليات مناسبة للغرض لدعم الفريق بنوايا واضحة وأنشطة يمكن التنبؤ بها.
فريق منفصل للغاية بمهارات مميزة
تخيل أن الفريق لديه مطورون ماهرون ومستقلون تمامًا ولديهم القدرة على الوفاء بوعودهم وتقديم محتوى العدو المتفق عليه في الوقت المناسب قبل نهاية السباق. حتى في مثل هذا السيناريو المثالي (الذي من غير المرجح أن يحدث على أي حال) ، سيواجه الفريق مشاكل في مواكبة ميزات التراكم (المتزايدة باستمرار) إذا تم فصل المهارات بشكل صارم بين أعضاء الفريق.
أمثلة قليلة
- يمتلك الفريق 1 أو 2 من مهندسي DevOps القادرين على إجراء أي تغييرات على خطوط الأنابيب المؤتمتة أو الاهتمام بالخدمات داخل النظام الأساسي ، لكن بقية الفريق ليس لديهم أدنى فكرة عن مثل هذه الأشياء. بعد ذلك ، ستؤدي مناقشة تلك القصص حول احتفالات سكروم مثل التحسينات إلى إضاعة الوقت لغالبية الفريق بالتعليق على الاجتماع دون أي مشاركة والعكس صحيح – لن يهتم مطور DevOps ببقية القصص الموجهة للوظائف ، و سيتم إهدار وقت الاجتماع في الغالب أيضًا.
- يوجد خبير قاعدة بيانات واحد للفريق بأكمله. اعتمادًا على مدى تعقيد واستخدام حلول البيانات في النظام الذي يطوره الفريق ، قد يكون هذا الشخص مثقلًا باستمرار بالقصص التي ليس لديهم فرصة لإكمالها قريبًا بما فيه الكفاية ، خاصة عند أخذ أولوياتهم في الاعتبار. والأسوأ من ذلك ، سيتعين على القصص الأخرى الانتظار أيضًا ، حيث تعتمد على مصدر البيانات الذي توفره قصص قاعدة البيانات.
- عندما يكون منتج معين موجهًا في الغالب نحو تطوير الواجهة الخلفية ، فإن مطور الواجهة الأمامية الوحيد موجود فقط في حالة (لأنه من وقت لآخر ، هناك حاجة إلى بعض التغيير الصغير حتى في تطبيق واجهة المستخدم على أي حال). في هذه الحالة ، مرة أخرى ، تكون معظم احتفالات سكروم مضيعة للوقت لعضو الفريق هذا ، لأن معرفتهم تقتصر فقط على الواجهة الأمامية ، ولا شيء آخر يهم.
حيث تنتهي
في أي من الحالات المذكورة أعلاه ، تكون النتيجة أن الأشخاص إما يضيعون وقتهم أو ، بدلاً من ذلك ، غير قادرين على اللحاق بالطلب المتراكم. إنهم يمنعون بقية الفريق من بدء العمل في القصص التالية ، أو أنهم يقللون بشكل فعال من الفعالية الإجمالية لفريق سكرم لأن هناك الكثير من الوقت الذي لا يتم استخدامه في السباق.
ومع ذلك ، لا يزال لدى الفريق هذا العدد من المطورين. من الخارج ، ليس من الواضح (حتى لو لم يرغبوا في الكشف عنهم) أن الأشخاص داخل الفريق غير قادرين على أخذ بعض القصص لمجرد أنهم موجهون للغاية لبعض المهارات المحددة. لذلك لا يمكنهم مساعدة أعضاء الفريق الآخرين بالقصص ، حتى لو سمحت قدرتهم بذلك ، كما أن أولويات القصص ستفضلها أيضًا.
حتى أنه من الصعب على مالك المنتج أن يؤلف بعض المحتوى ذي المعنى السريع للفريق ، حيث يجب على مالك المنتج دائمًا أن يأخذ في الاعتبار عدد الأشخاص الذين يمكنهم العمل على كل قصة واحدة وإذا تم إحضار المزيد من القصص المماثلة إلى السباق في نفس الوقت ، في النهاية يتم تجاوز قدرة الفريق ، حتى لو كان هناك أشخاص في الواقع يمكن أن يعملوا على تلك القصص ، لكن ليس لديهم المهارة للبدء بها.
حل المعضلة
إنها معضلة يجب حلها ، ويجب أن يكون مديرو المشاريع على دراية بالطريق الذي يجب عليهم الاختيار. على وجه التحديد ، الاختيار بين:
- وجود العديد من مطوري البرامج الكاملة القادرين على العمل على محتوى أوسع ، ولكن ليسوا خبراء في العديد من الموضوعات. حتى يتمكنوا من التوسع ولكن ليس العمق. ثم يمكن أن يتقدم التسليم بسرعة ، ولكن قد تتأثر الجودة.
- وجود خبراء متخصصين لكل تقنية ، ولكن بعد ذلك قبول القيود والعمل بجدية أكبر على محتوى مطبوع بشكل أفضل. بعد ذلك ، يمكن للناس التعمق في إنشاء قصص رائعة ، ولكن يجب التعامل مع القصص بشكل متسلسل ، وبالتالي يستغرق وقتًا أطول لتقديمها.
صاحب المنتج الضعيف
هذه ليست بالضرورة “مشكلة عملية” بحكم التعريف ، لكنني أتعامل معها على هذا النحو لمجرد أن إنشاء القصص الصلبة يمكن فهمه على أنه عملية يجب أن يرغب الفريق في الحصول عليها بشكل قوي ومتوافق مع فريق التطوير.
ما أعنيه بالضعف لا يحتاج إلى الإشارة إلى الملكية المعرفية للفرد ، ولكن بالأحرى إلى قدرة مالك المنتج على خدمة قصص الفريق التي يمكن للمطورين فهمها والتي يكون لها معنى واضح من منظور خارطة طريق المنتج. كلاهما مهم جدًا لفريق سكرم ناجح.
إذا كانت القصص تفتقر إلى التفاصيل للمطورين حتى يتمكنوا من فهم الغرض أو القيمة الوظيفية أو التوقعات الفنية بوضوح ، فيمكن أن يحدث سيناريوهان أساسيان:
- سيبني المطورون شيئًا مختلفًا عما يريده مالك المنتج بالفعل. حتى أنه من الصعب الإمساك به أثناء السباق نفسه لأن مالك المنتج في الغالب لم يكن لديه القدرة على تتبع تقدم القصص على هذا المستوى التفصيلي ، وفي الغالب يتوقع PO فقط أن يحدث الشيء (بطريقة سحرية).
- سيقضي المطورون الكثير من الوقت في توضيح القصص ومناقشتها مرارًا وتكرارًا بدلاً من البدء في بنائها. يتضمن ذلك العديد من المكالمات الإضافية والاتفاقيات المتكررة وتأجيل العمل إلى مرحلة العدو المتأخر. يصل إلى نقطة حيث لم يعد من الممكن اعتبار التقديرات الأصلية للقصص دقيقة ، ولا يمكن إغلاق القصص داخل العدو وتدور في سباقات السرعة التالية. في أسوأ الحالات ، يتكرر الموقف بعد ذلك في سباقات السرعة اللاحقة.
حان الوقت للتأمل الذاتي
عادة ما يكون من الصعب الاعتراف ، ولكن يجب على مالك المنتج إيجاد الوقت للتفكير ، والنظر في قصص الأعمال المتراكمة التي تم إنشاؤها ، ومقارنتها في النهاية برؤية خارطة طريق المنتج إذا كان لا يزال هناك أي رابط معقول بين هذين – إذا كان هناك أي خارطة طريق على الاطلاق. إذا لم يكن الأمر كذلك ، فهذا هو أول شيء يجب حله. في بعض الأحيان ، يكون الحل هو الاعتراف بأن مالك المنتج بعيد جدًا عن الفريق وبعيدًا جدًا عن هدفه.
في مثل هذه الحالة ، يجب حل جزء مالك المنتج من الفريق. إذا لم يكن هناك شيء آخر ، فإن جلب محلل أعمال قوي إلى الفريق وموجه أكثر نحو محتوى الفريق بدلاً من محتوى الأعمال (لذلك ، لدينا بالفعل مالك منتج في هذه الحالة) يمكن أن يكون خيارًا صالحًا للذهاب إليه ، حتى بالنسبة لسعر زيادة التكاليف الإجمالية للفريق.
عمليات الاختبار بدون جدول زمني ثابت
ماذا لو لم تكن أنشطة الاختبار ضيقة لجدول زمني محدد داخل سباق سكروم؟
للوهلة الأولى ، قد يبدو هذا شيئًا جيدًا نريده لفريق رشيق / سكرم. المرونة موضع ترحيب دائمًا وتبدو جيدة عند تقديمها في الخارج.
تُظهر تجربتي أن نتيجة هذه الحرية هي فوضى أكثر من مرونة. هذا لا يعني أن الحل لهذا يجب أن يكون إنشاء “شلالات داخل العدو” مع مراحل اختبار مخصصة تتبع بعد الانتهاء من التطوير مباشرة. هذا ليس بأي حال من الأحوال النهج الصحيح في هذه الحالة. يمكنك قراءة المزيد حول هذا الموضوع في منشوراتي حول استراتيجية اختبار سكروم ودورة حياة اختبار رشيقة.
لا يزال بإمكاننا السماح ببعض المرونة واختيار جدول الاختبار لأنه يبدو أكثر ملاءمة لفريق التطوير الحالي وخصائص المنتج المحددة التي يقدمها الفريق. ومع ذلك ، هناك هدفان رئيسيان يجب تحقيقهما من خلال هذا الاختيار:
إذا تم استيفاء هذه الشروط ، فسوف يتكيف الفريق بشكل طبيعي مع عملية التركيب ، ولن يتأثر جدول التسليم بأنشطة الاختبار المطولة غير المخطط لها.
في النهاية ، ما يهم أكثر هو إصدار سريع يمكن الاعتماد عليه ويمكن التنبؤ به ، وهو ما يقودني إلى آخر نقطة في هذه المدونة.
عملية الإصدار غير المحددة
الآن ، هذا شيء واضح لكل فريق سكرم. ومع ذلك ، من الغريب أنها عادة ما تكون أيضًا واحدة من أكثر العمليات التي يتم التقليل من شأنها.
في كثير من الأحيان ، سيقول فريق سكرم فقط أن الإصدار سيكون بعد كل سباق ، لكن لا يتم دعمه من خلال عملية قوية. ما يحدث بعد ذلك ، في الواقع ، هو أن الكثير من الأنشطة الفوضوية التي لا يمكن التنبؤ بها ستظهر خلال وقت الإصدار. فجأة ، ينشغل جميع الأشخاص بـ “مهام الإصدار” ، ولا أحد قادر على التركيز على الاستمرار في تطوير قصص العدو الجديدة. تم إيقاف تشغيل مقاييس Sprint ، ويبدو الإصدار وكأنه نشاط عشوائي لا يمكن التنبؤ به من وجهة نظر الشخص الثالث (عادةً العميل).
يركز الناس بشكل كبير على الأعمال المتراكمة ، ومحتوى السباق ، والتطوير ، والاختبار ، وأخيرًا عرض النتائج حتى أنهم نسوا أنه بمجرد الانتهاء من كل هذا ، فإن السباق التالي مستمر بالفعل ، وهم يضيعون الوقت بالفعل.
تبحث عن وقت مناسب للإفراج عنك
إذن متى بالضبط يجب على الفريق أن يقوم بالإصدار الفعلي للإنتاج؟ الشيء الوحيد المهم الذي يهم في النهاية.
تكمن الإجابة على هذا السؤال في هذه العملية ، على افتراض أن لديك واحدة. اعتمادا علي:
- مدى تعقيد المحتوى الذي ينتجه الفريق في سباقات السرعة ،
- مدة العدو ،
- عدد المكونات المتأثرة في النظام
- عدد الأشخاص الذين يستخدمون التغييرات ويطلبونها ،
يجب إنشاء عملية إطلاق متكررة ومتابعتها من الآن فصاعدًا. يمكن أن تكون القواعد الدقيقة للعملية مرنة مرة أخرى في التحديد. ولكن كما هو الحال مع أنشطة الاختبار ، فإن جعلها عادة صلبة يمكن التنبؤ بها وجدولتها لأيام ملموسة في المستقبل يجعلها شيئًا يمكن الاعتماد عليه والرجوع إليه.
اختيارات للاختيار
يمكن أن تكون الأشكال المحتملة لهذه العملية أيًا مما يلي أو غيرها:
- أكمل اختبار الميزات من السباق الحالي خلال السباق التالي وحرر المحتوى في نهاية هذا العدو (بمجرد اكتمال الاختبار). هذا يعني أن كل إصدار لن يحتوي على أي محتوى من آخر سباق سريع ولكنه سيحتوي على قصص من السبقين السابقين.
- آخر سباق قبل الإصدار مخصص دائمًا لاختبار المحتوى من السبقين السابقتين.
- هذا لا يعني أنه سيتم إيقاف التطوير أثناء “سباق الاختبار” ؛ تقول فقط أن المحتوى الذي تم تطويره في هذا الاختبار السريع لن يتم تضمينه في الإصدار التالي حتى الآن.
- إذا كان هناك ما يكفي من أنشطة الاختبار الآلي المعمول بها بالفعل ، فاحرص على إجراء الإصدار بعد نهاية كل سباق. إذن يجب أن تكون هذه عملية صارمة للغاية مع أشخاص متفانين يركزون على تلك الأيام القليلة بنسبة 100٪. لا يزال يجب ألا يؤثر على بقية فريق التطوير بأي شكل من الأشكال.
- يمكنك أيضًا اختيار الإصدار مرة واحدة شهريًا أو مرة واحدة لكل N شهرًا ، خاصة إذا كان ذلك سيكون جيدًا من وجهة نظر المستخدمين النهائيين. سيؤدي ذلك إلى زيادة الجهد المبذول على جانب الاختبار لكل سباق (حيث سيكون المحتوى أكبر لكل إصدار). ولكن من ناحية أخرى ، سيعني ذلك قدرًا أقل من الأنشطة المتكررة بمرور الوقت ، والتي في هذه الحالة ، يمكن أن يكون لها فوائد للفريق. نتيجة لذلك ، يمكنه تمكين الفريق من بناء المزيد من الميزات الجديدة بين الإصدارات ، على الرغم من حقيقة أن الميزات ستظهر في الواقع مع إيقاع أبطأ.
ولكن كما ذكرنا عدة مرات من قبل ، ليس من المهم تحديد أي من هذه العمليات سيتم اختياره. والأهم من ذلك بكثير مدى جودة التزام الفريق بهذه العملية وجعلها عادة صعبة التحمل.
يمكنك أيضًا قراءة هذا الدليل الخاص بعملية وممارسات إدارة الإصدار.
