من هم مطورو سكروم المحترفون؟ دليل 2023

كل شخص هو مطور في فريق التطوير وليس مجرد مبرمج أو مختبِر أو ما إلى ذلك.
Scrum هو إطار عمل بسيط للغاية لتطوير منتجات برمجية معقدة في بيئة معقدة ولكن من الصعب ممارسته. لكن لماذا؟ لن أخوض في التفاصيل حول السبب ولكنني أردت تسليط الضوء على مشكلة واحدة في فريق التطوير حسب فهمي.
فريق التطوير يعني فريقاً متعدد الوظائف ومنظم ذاتياً من المطورين. ولكن من هو المطور؟ أليس كل من يساهم في تطوير البرمجيات؟ مبرمج أو مختبِر أو مسؤول برمجة أو مصمم واجهة مستخدم أو كاتب محتوى أو محلل أعمال؟
الآن، انظر إلى فريقك. هل هو متعدد الوظائف؟ نعم، لديك لأن لديك تقنيون لجميع المهارات ولكن هل هؤلاء التقنيون مطورون؟ ربما لا. هناك فقط مبرمج ومختبر ومبرمج ومختبر ومدير برمجة ومصمّم واجهة مستخدم، وينتظرون مهامهم المتعلقة بمهاراتهم.
إنهم لا يعملون كمطورين بهدف تطوير البرمجيات ولكنهم يقومون بمهامهم حسب مهاراتهم فقط. بعض الأشياء الأساسية التي ستساعدك على فهم خصائص فريق التطوير. لنفترض أن قسم التعلم والتطوير (قسم التعلم والتطوير) على وشك تنظيم تدريب وإعلان على النحو التالي الإعلان الأول “نحن نخطط لعقد ورشة عمل لمطوري سكروم لذا أرسل ترشيحك”.
ستجد أن المبرمج فقط قد اشترك في ورشة العمل هذه. إعلان آخر “نحن ننظم ورشة عمل للاختبارات الرشيقة لذا أرسل ترشيحك”. هذه المرة سيشترك المختبر فقط. ما الذي يعكس ما سبق؟ لا يزال الفريق منقسمًا على أساس مهارات البرمجة والاختبار. يشعر المختبرون أن كل ما يتعلق بالاختبار هو مجال عملهم، وبالمثل يشعر المبرمجون أن كل أعمال الترميز جزء من عملهم. ولكن في الواقع يقوم المختبرون بكتابة التعليمات البرمجية من أجل اختبار التعليمات البرمجية للإنتاج، ويقوم المبرمجون بكتابة الاختبارات لإجراء اختبارات الوحدة والتكامل للتعليمات البرمجية.
طريقة أخرى للنظر إلى الأمر – أثناء التخطيط للسباق السريع أعد فريق التخطيط للسباق السريع أدناه. ما الذي يعكسه؟ هناك مهام ولكن هذه المهام تعتمد على المهارات وليس على المكونات. أليست هذه طريقة سيئة لإنشاء المهام؟ إذا لم تكن كذلك؟ ثم اقرأ الموقف أدناه.
لنفترض أن هناك شخصين أليكس (المبرمج) ومارثا (المختبر) يعملان على هذه القصص الثلاث. انتهى أليكس من الجزء البرمجي من القصة 1 في يومين وبدأت مارثا في الاختبار، فماذا سيفعل أليكس بعد ذلك؟ على الأرجح سيبدأ أليكس العمل على جزء الترميز من القصة 2.
لكن هل هو جيد؟ لماذا لا يمكن لأليكس التقاط عمل آخر من نفس القصة؟ أو لماذا كانت مارثا تنتظر أن يكمل أليكس الترميز من أجل البدء في الاختبار؟ لماذا لا يمكنها الاقتران مع أليكس للاختبار بالتوازي أو على الأقل البدء في اختبار واجهات برمجة التطبيقات؟ سألني الكثير من الناس ما الخطأ إذا بدأ أليكس العمل على جزء الترميز من القصة 2. دعونا نرى الوضع أدناه.
أكمل أليكس ترميز القصة الأولى وبدأ ترميز القصة الثانية. وجدت مارثا خطأ في القصة الأولى فماذا عليها أن تفعل؟ تواصلت مع أليكس وأرادت أن تناقشه في الأمر لكن أليكس مشغول وطلب منها أن تأتي في وقت لاحق. ماذا ستفعل مارثا بعد ذلك؟ على الأرجح أنها ستفتح أداة تتبع الأخطاء وتسجيل الخطأ المكتشف حديثًا هناك.
هل هذا جيد؟ لا، ولكن لماذا لا؟
سأكتب عن تحديات تسجيل الأخطاء بشكل منفصل ولكن دعنا نركز على الجانب الآخر منها الآن. بعد يوم واحد انتهى أليكس من ترميز القصة 2 وبدأ يبحث في الأخطاء التي سجلتها مارثا. لقد حدد سبب مسار الخطأ والتغييرات البرمجية على مستوى الإطار اللازمة لإصلاحه. لكن ذلك سيؤثر أيضًا على الكود الذي أكمله للتو للقصة 2. ماذا سيفعل أليكس؟ جيد إذا قام بتغيير كل ما يلزم من أجل إصلاح المسار ولكنه سيؤدي إلى إعادة العمل وسيؤخر التسليم. هناك خيار آخر هو الاختصار لإصلاح الخلل (الترقيع) لذا لن يكون له تأثير كبير على كود القصة الثانية.
في معظم الأحيان يختار المبرمجون الخيار الثاني لأن المبرمجين عاطفيون جدًا بشأن الكود الخاص بهم (أمزح فقط). هناك أسباب متعددة لاختيار الخيار الثاني ولكن النتيجة النهائية ستكون “الديون التقنية”.
ما الذي يمكن فعله لتجنب مثل هذا السيناريو؟ نعم، أولاً لا تقم بإنشاء مهام كما هو مذكور أعلاه ولكن حاول أن تقسمها إلى مكونات. الأفضل هو عدم إنشاء مهام ولكن لا تزال هناك حاجة إليها ثم تقسيمها إلى مكونات. العمل في إقران. يجب أن يركز الفريق على إنهاء مهمة قيد التنفيذ بالفعل بدلاً من بدء قصة جديدة.
شكرًا على القراءة! إذا كان لديك أي استفسار فتواصل معي.