3 مطبات من سكروم وكيفية إصلاحها

دعنا نتخلص من الاجتماعات الفظيعة الرهيبة وتقدير الجحيم وتوفير قيمة للمستخدم وبناء منتجات رائعة بدلاً من ذلك.

تصوير راندي فتح على Unsplash

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

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

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

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

في هذه المقالة ، أفكر في ما تعلمته منذ كتابة المقالة السابقة ، وكيف أعتقد أن سكروم يمكن أن يساعدك أنت وفريقك في بناء برامج أفضل.

قم بعقد اجتماعات يومية مفيدة

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

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

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

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

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

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

تصوير روب هامبسون على Unsplash

لا تستحوذ على قيمة المستخدم

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

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

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

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

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

لا تأخذ تقديرات للإنجيل

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

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

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

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

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

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

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

خاتمة

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

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

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

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

أفضل طريقة لتطوير البرامج هي الطريقة التي تعمل بها لفريقك. ركز على ذلك. انسى الباقي.