المشاكل العشرة التي تؤدي إلى إبطاء سير عمل التطوير لديك (وكيفية إصلاحها)
إن قلب أي فريق هندسي هو سير العمل الخاص به – كيف تنتقل المشاريع من التفكير إلى منتج عملي، وكيف تنتقل تعليقات العملاء من تذكرة إلى أحدث سباق.
لم تكن الفرق الهندسية بحاجة أبدًا إلى حافز خارجي للتحسين، فالتكرار أمر أساسي في الوظيفة.
ومع ذلك، الآن أكثر من أي وقت مضى، فإن توقعات العملاء المتزايدة فيما يتعلق بالسرعة والجودة يجب أن تؤدي إلى تحسينات دائمة في سير عملك.
لماذا العمليات الرسمية على الإطلاق؟
على الرغم من أن الهدف من Agile هو أن يكون مرنًا ويتيح مساحة للتحولات والمحورات السريعة، إلا أن هناك تقليدًا طويلًا يتمثل في “القدر الكافي” فيما يتعلق بالعملية والتصميم والاختبار.
النقطة المهمة هي أنك تحتاج إلى بعض العمليات التأسيسية، حتى لو كانت في حدها الأدنى.
على مستوى عالٍ، تبدو معظم عمليات تطوير Agile متشابهة، حتى Kanban أو Scrum. كلاهما يعطي الأولوية للتحولات السريعة والتحسينات المستمرة التي تحقق النتائج. معظم الأنظمة، حتى العمليات البسيطة، سيكون لها بعض نكهة هذه الخطوات الأساسية الخمس:
- تذكرة جديدة
- تطوير
- مراجعة
- اختبارات
- تعيين
قبل الغوص في الأعشاب الضارة، افحص سير عملك من مسافة حرجة. كم عدد الخطوات الموجودة في نظامك؟ كم كان عددهم قبل عام أو عندما قام فريقك بتنفيذ سير العمل لأول مرة؟
من المحتمل أن تكون عمليتك قد تطورت مع مرور الوقت، ولكن ليس بالضرورة نحو الأفضل. يمكن أن يصبح سير العمل مشوشًا بسبب الخطوات الإضافية التي تؤدي إلى حدوث اختناقات وتأخير أوقات الدورة.
على سبيل المثال، حدث خطأ ما خلال سباق سريع، ونتيجة لذلك، أضاف فريقك خطوة مراجعة ثانية في النهاية. أسرع طريقة لتحسين سير عملك هي إزالة العمليات الزائدة أو غير الضرورية.
الآن بعد أن استكشفنا سير العمل من ارتفاع 1000 قدم، فلننتقل إلى مستوى الأرض.
يمكن تحسين كل خطوة في النظام بدءًا من التذكرة الجديدة وحتى النشر لتحقيق السرعة والكفاءة، والعمل معًا في تناغم لإنشاء تحسينات دائمة على سير عملك.
في كل خطوة، نحدد الأنماط والسلوكيات الإشكالية التي قد تتعرف عليها عبر فريقك والحلول التي يمكنك استخدامها لمعالجتها وحلها، وتحديد أوقات الدورات وتحسين تدفق الكفاءة.
الخطوة 1: التذاكر الجديدة
يبدأ العمل بتذكرة جديدة، فكيف يمكنك إخراجها من الباب؟ إن كيفية تفاعل المهندسين مع التذاكر الجديدة لها عواقب دائمة عبر المهلة الزمنية ومدة الدورة وسير العمل.
المشكلة: يستغرق مدير المشروع وقتًا طويلاً لتعيين تذاكر جديدة
ستجد دائمًا أن المهلة الزمنية الخاصة بك، أو الوقت الذي يبدأ منذ أن يرسل العميل تذكرته ويرى النتيجة، يظل خارج هدفك مباشرةً.
الإصلاح: استخدم نظام السحب
تسمح أنظمة السحب للمهندس بالتقاط عمل جديد عندما يكون جاهزًا. تدخل المهام الجديدة باستمرار إلى مسار التحويل، وعندما ينهي المهندسون تذكرة واحدة، يمكنهم الانتقال بسهولة إلى الأخرى.
لا داعي للقلق بشأن ما يجب عليهم فعله ويظل العمل بتدفق مستمر.
المشكلة: التذاكر بطيئة ووصل الفريق إلى الحد الأقصى
بدأت التذاكر الجديدة تتراكم وتتحرك بشكل أبطأ فأبطأ خلال سير العمل على الرغم من أنك تستهلك الحد الأقصى من الموارد المتاحة للفريق.
الحل: البدء في تحسين كفاءة التدفق
تحسين كفاءة التدفق بدلاً من كفاءة الموارد. كفاءة التدفق هي النسبة بين الوقت النشط والوقت الإجمالي لمهمة ما، ويمكن أن تساعدك على فهم العمل الجاري بالفعل.
وإليك السبب: إذا تم منح المطور أربعة أيام لإنشاء ميزة ما، فقد يشير عبء العمل الخاص به وفقًا لكفاءة الموارد إلى أنه تم استغلاله. ولكن، إذا كانوا بحاجة إلى يوم واحد فقط من العمل المركّز لإنجازه، فإن ذلك يعادل كفاءة تدفق تبلغ 25%. تركز كفاءة الموارد أيضًا بشكل أكبر على القيام بالمزيد من الأشياء في وقت واحد.
البشر غير قادرين من الناحية الفنية على القيام بمهام متعددة، لذا لا ينبغي أن يكون الهدف هو القيام بالمزيد في وقت واحد. يجب أن يكون الهدف هو تحسين سرعة المهمة.
لا يزال التركيز على كفاءة التدفق يجعل الفريق مشغولاً، لكنهم قادرون على التركيز على إكمال مهمة واحدة في كل مرة بإيقاع طبيعي.
الخطوة الثانية: التطوير
يتم تنفيذ جوهر العمل في مرحلة التطوير ولكن من السهل تأخير المهام أو اختناقها منذ البداية. للحفاظ على التدفق الجيد، من المهم إزالة حواجز التطوير.
المشكلة: تباطؤ مرحلة التطوير
تستغرق مرحلة التطوير الخاصة بك وقتًا أطول من المتوقع بسبب واحد أو أكثر من الأسباب التالية: مقدار غير معتاد من الوقت في إعادة البناء، أو الاضطراب الشديد، أو ارتداد التذاكر إلى الخلف في سير العمل.
الحل: التحقق من عدم وجود خلل كبير وإعادة البناء والتدفق العكسي
على الرغم من أهمية تحسين الكود القديم، إلا أنه غالبًا ما يؤدي بالمطور إلى خارج نطاق التذكرة. يمكنك اكتشاف ذلك من خلال البحث عن مستويات عالية من إعادة الهيكلة القديمة.
لا تثبط بالضرورة هذا العمل، فهو مهم، ولكن شجع المطور على اتباع نمط عمل أكثر رسمية.
طلب منهم، جنبًا إلى جنب مع فريقك بأكمله، الإبلاغ عن التحديثات المطلوبة التي يمكنك إرسالها كمهمة لاحقًا، مع الأخذ في الاعتبار النطاق الشامل والعمق الذي يتطلبه المشروع.
إذا كان فريقك يعاني من مستويات تخلف أعلى من المعتاد أو أن التذاكر تستمر في التحرك ذهابًا وإيابًا في عملية التطوير، فقد تكون هناك مشكلات تتعلق بمتطلبات التذاكر إما التي تتغير أثناء الرحلة أو مفقودة تمامًا.
قم بمراجعة التراجع والتدفق العكسي للتذكرة بانتظام مع فريقك لفهم اتجاهات إعادة البناء والتراجع والتدفق العكسي. سيسمح هذا للفريق باكتشاف المشكلات ومعرفة مكان الاستراحة في العملية.
المشكلة: عضو الفريق مثقل
ترى تراكم العمل خلف أحد أعضاء الفريق، على الرغم من أن جودة عملهم تكون دائمًا على مستوى عالٍ. لاحظت أيضًا أن المطورين الآخرين يقومون بتسليم مهام معينة لهذا الشخص.
الحل: قم بتدريب الفريق لنشر العمل
يحتوي كل فريق على خبير أو اثنين من الخبراء الذين يقومون بأعمال عنق الزجاجة عن غير قصد.
إذا كانت خبرتهم في مجال ما تقع في مجال بالغ الأهمية، ففكر في التدريب المتبادل لأعضاء الفريق الآخرين وقم بتعيين هذه المهام يدويًا لعدة أشخاص. يمكنك أيضًا أن تطلب من خبير المجال إجراء التدريب.
وفي الوقت نفسه، قم بتكليف بطل المجال بمهام أخرى تساعده على صقل مهاراته.
الخطوة 3: المراجعة
تعد مرحلة المراجعة فرصة للتعاون وحل المشكلات معًا. إذا كان الأمر متسرعًا أو مضغوطًا جدًا، فسترى المزيد من المشكلات وتؤدي إلى تباطؤ الخط.
المشكلة: أزمة مراجعة التعليمات البرمجية
قد ترغب في إجراء مراجعات التعليمات البرمجية بشكل متكرر أكثر عند الالتزامات الصغيرة، ولكن بدلاً من ذلك، فإنها تميل إلى أن تحدث في نهاية السباق.
لا يحب أعضاء الفريق مشاركة التعليمات البرمجية الخاصة بهم حتى يعتقدون أنها مثالية.
الحل: التركيز على التسليم المستمر
قد لا تشارك الفرق عملها مع بعضها البعض لأنهم يشعرون أنهم مؤهلون بشكل فريد لإكمال مهمة ما، أو يخشون من حكم أقرانهم أو أن المواعيد النهائية للعدو السريع تؤدي إلى نهاية دورة الاندفاع.
لمعالجة أول مشكلتين محتملتين، قد تحتاج إلى إرسال العمل في وقت معين قبل المراجعة أو تنفيذ خطوة منتصف الطريق التي تجذب مجموعة أخرى من الأنظار إلى الكود. بشكل أقل رسمية، يمكنك تشجيع التعاون في اجتماعات الفريق، أو إضافة وقت لمراجعة تعليمات برمجية صغيرة، أو عن طريق تسهيل التعاون يدويًا بشكل فردي، مما يساعد المطورين على توجيه أعضاء فريقهم للحصول على المساعدة.
إذا كنت تشعر أن المشكلة مرتبطة بدورات الركض السريع التي تدفع المراجعات إلى اللحظة الأخيرة، فإن تحويل تركيز فريقك على تقديم قيمة مستمرة للعملاء، بدلاً من إنهاء السباق، يمكن أن يساعد في تخفيف أزمة نهاية السباق.
المشكلة: طلبات السحب في اللحظة الأخيرة
عندما تأتي طلبات السحب الكبيرة مباشرة في نهاية السباق، يمكن أن يجعل ذلك الفريق يشعر بالاندفاع الشديد وعدم القدرة على إعطاء الوقت المناسب لعملية المراجعة.
وبالمثل، غالبًا ما تحتوي التعليمات البرمجية على المزيد من الأخطاء حيث لم يتم اكتشافها مسبقًا بواسطة مطور آخر أو لم يتم فحصها بشكل غير رسمي.
الإصلاح: إنشاء إيقاع أفضل
عندما يقوم شخص ما بإسقاط طلبات سحب كبيرة في نهاية سباق السرعة، أو كود التخزين، فإنه يخلق أزمة غير ضرورية في اللحظة الأخيرة.
قد يرسل المهندسون النموذجيون عمليات السحب المكتملة عدة مرات في اليوم، في حين قد يرسل مكتنز الكود مرة واحدة فقط في الأسبوع.
يتطلب العمل مع مكتنز الأكواد مزيدًا من التعاطف – فمن المحتمل أنهم أنهوا للتو الكثير من العمل وقد يشعرون بالإرهاق. إذا كان الأمر يتعلق بواحد أو اثنين من المطورين، تعامل مع الموضوع بشكل عرضي؛ اجعلهم يتحدثون عن طلب السحب الأخير الخاص بهم وكيف شعروا بأن العملية سارت.
وقد لا يدركون كل المساعدة المتاحة لهم أو لا يرون فوائد الالتزامات والمراجعة المتكررة. ولمساعدتهم في التغلب على ذلك، يمكنك تنفيذ ثقافة التحقق من التعليمات البرمجية على فترات زمنية قصيرة ومنتظمة.
من خلال إنشاء إيقاع منتظم لإرسال التعليمات البرمجية،
إذا كان يبدو أن الاكتناز أكثر انتشارًا بين الفريق، فمن الجيد إنشاء أو إعادة تأسيس قيم الفريق حول التقدم المتزايد وتقديم تحسينات مستمرة.
الخطوة 4: الاختبار
الاختبار هو الاختبار الحقيقي لجميع الأعمال التي تم تقديمها من قبل ويكشف عن أوجه القصور في أجزاء أخرى من نظامك. سواء قمت بإنشاء اختبار مقدمًا أو بعد تنفيذ التعليمات البرمجية، فهي خطوة حاسمة قبل النشر.
المشكلة: قطع الحل
أثناء اختبار الكود، تعلم أن الحل لا يتطابق تمامًا مع المشكلة الأصلية في التذكرة. إذا نظرنا إلى الماضي، ربما لم تكن التذكرة بهذا الوضوح من البداية.
ترى تغيرًا كبيرًا والكثير من الارتعاش، أو ذهابًا وإيابًا بين المطور ومقدم التذكرة. ينتهي الأمر بالتطوير مرة أخرى، مما يؤدي إلى إبطاء أوقات الدورة.
الحل: توضيح متطلباتك
لكي تكون فعالة، يجب أن تصف قصص المستخدمين أو المدخلات الأصلية نتيجة واضحة. هذا لا يمكن المبالغة فيه.
كلما كان الهدف أو قصة المستخدم أكثر واقعية، قلت احتمالية التغيير. على سبيل المثال، التذكرة التي تقول “أصلح الزر الموجود على الصفحة المقصودة” ستؤدي إلى مزيد من التغيير مقارنة بقصة المستخدم التي تقول “أضف انتقال التمرير من اللون الأزرق إلى الأخضر على زر الصفحة المقصودة”، أو الأفضل من ذلك، ” لا يتغير زر الصفحة المقصودة عند المرور فوقه.
يرجى تحويله من اللون الأزرق إلى اللون الأخضر.
كلما كان الإصلاح أكثر تعقيدًا أو متعدد المراحل، زادت أهمية الحصول على مدخلات واضحة.
قد يكون عدم الوضوح بشأن المدخلات نتيجة لمتطلبات غير واضحة، أو عدم فهم النظام مسبقًا أو الكثير من المشكلات الأخرى، ولكن إنشاء مدخلات ملموسة تقع على عاتق كل من المهندس وقائد المنتج.
الالتزام بعملية إصدار التذاكر الواضحة، بما في ذلك إرسال التذاكر التي بها مشكلات إلى جزء سابق من سير العمل.
سيسمح ذلك بتطوير البيانات لتوفير الرؤى اللازمة حول التدفق العكسي للتذاكر وآثاره على دورة الإنتاج الخاصة بك.
المشكلة: زحف النطاق والتردد
بالإضافة إلى الارتعاش الأولي، ترى الكثير من التحركات ذهابًا وإيابًا بين المطورين أثناء تحرك التذكرة عبر النظام. يتجاوز شخص ما النطاق المقصود أو يؤدي تردد مدير المشروع إلى تغييرات في منتصف سير العمل.
الحل: حافظ على تواصلك واضحًا
مرة أخرى، يجب أن يكون للتذكرة هدف واضح وبسيط. أي شيء يُترك مفتوحًا للتفسير يمكن تفسيره بشكل مختلف، مما يخلق المزيد من النقاش ذهابًا وإيابًا حول ما يجب إنجازه بالفعل.
ولكن بعيدًا عن الأهداف الواضحة، هناك المزيد الذي يمكنك القيام به لتجنب لعبة الهاتف بين أعضاء فريقك. يمكنك تحسين عمليات التسليم عن طريق الاحتفاظ بجميع المعلومات داخل أداة إدارة العمل نفسها.
تقليل المبلغ الذي يتم تمريره عبر البريد الإلكتروني أو المحادثات. أي شيء يتطلب من مالك المهمة الجديد البحث عن المعلومات أو توضيح المهمة أو تغيير الأدوات سيزيد من وقت الدورة.
الخطوة 5: النشر
في هذه المرحلة، يجب أن يخرج العمل من الباب ويعود المطورون إلى بداية العملية. ما الذي يعيق الأمور؟
المشكلة: إصلاحات رمز اللحظة الأخيرة
بحلول الوقت الذي تصل فيه التعليمات البرمجية الخاصة بك إلى مرحلة النشر، فإنك تتوقع شحنها بسرعة فقط لتجد أن هناك مشكلات في اللحظة الأخيرة تعيدها مرة أخرى إلى التطوير أو المراجعة أو الاختبار.
الحل: قم بتعيين توقعات جديدة للمراجعة
إن Heroing، أو إصلاحات التعليمات البرمجية في اللحظة الأخيرة، على الرغم من كونها مفيدة، إلا أنها تشير إلى حدوث خلل ما في وقت مبكر من العملية.
في أسوأ الأحوال، يمكن للفريق انتظار تدخل البطل، ويصبح الإصلاح في اللحظة الأخيرة خطوة متوقعة في العملية.
لا تقم بتمكين أو تشجيع الأبطال — بدلاً من ذلك، حدد التوقعات بأن فريقك يكتشف المشكلات في خطوات المراجعة والاختبار.
إذا لزم الأمر، قم بإنشاء مراجعة إضافية أو خطوة اختبار في سير العمل لتقليل تعديلات اللحظة الأخيرة إلى الحد الأدنى.
المشكلة: تضيف المراجعة اللاحقة
أيضًا في اللحظة الأخيرة، لديك أعضاء الفريق الذين يضيفون شيئًا واحدًا آخر فقط في نهاية السباق، عادةً بعد الموافقة على طلب السحب الرئيسي بالفعل.
الإصلاح: تحديد السبب وضبطه
كرر أنه بحلول الوقت الذي تصل فيه إلى النشر، يكون وقت الإضافات قد انقضى.
حان الوقت للشحن. حاول أن تفهم ما إذا كان هناك نوع معين من طلبات السحب المتأخرة شائع أم أنه مجرد مطور محدد يأتي في اللحظة الأخيرة.
إذا كان الأمر يتعلق بنوع من التعليمات البرمجية، فارجع إلى قصة المستخدم للتأكد من أنه يلتقط النطاق الكامل ويضع نتائج واضحة في الاعتبار.
إذا كان مطورًا محددًا، فاعمل معه لتقديم المزيد من الالتزامات المتكررة والتعاون مع الآخرين. ويمكن أن تكون أيضًا فرصة لإعادة تخصيص الموارد والوقت لأجزاء مختلفة من العملية.
تحديد الاختناقات أو التحولات الضيقة وتعديلها حسب الحاجة.
البدء
أكثر من أي وقت مضى، تتغير توقعات العملاء وتتوافق مع الواقع الجديد. لتلبية احتياجات عملائهم بشكل مستمر، يحتاج فريقك الهندسي إلى كل ميزة يمكنه الحصول عليها.
ابدأ بالبيانات لفهم الفروق الدقيقة وأنماط الفريق بشكل موضوعي لبناء تحسينات دائمة على سير عملك.
المصدر: pluralsight
قد يهمك:
