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

رأيت عدد المتغيرات Agile التي تسمى Scrum تقتل الشركة حقًا. بالقتل ، لا أعني "التدهور الثقافي" ، بل عندما تنخفض أسهم الشركة بنسبة 90٪ تقريبًا في غضون عامين.

ما هو رشيقة؟

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

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

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

شفافية عنيفة

هناك العديد من الاتجاهات في مكان عمل تكنولوجيا المعلومات التي تجعل مهنة البرمجة غير جذابة للغاية ، خاصة للأشخاص المبدعين والأذكياء.

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

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

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

عيوب رشيقة وسكروم محددة

1. تطوير الأعمال.

غالبًا ما يتم تقديم رشيق بالمقارنة مع "شلال". ما هو الشلال؟

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

يستنسخ الشلال النموذج الاجتماعي لمنظمة مختلة وظيفيا ذات تسلسل هرمي معين. في المقابل ، غالبًا ما يكرر Agile النموذج الاجتماعي لمنظمة مختلة دون التسلسل الهرمي المحدد بوضوح.

لدي آراء مختلطة حول المسميات الوظيفية مثل "كبار" و "مدير" وما شابه. هم مهمون ، وأنا على الأرجح لن أقبل بمنصب أقل من مستوى المخرج ، لكنني أكره أهميتهم. إذا نظرت إلى سكروم ، فإنها تحرم على وجه التحديد حقوق كبار المهندسين والأكثر قدرة ، لأنهم هنا ملزمون بالالتزام بالعمليات القائمة (العمل فقط في المهام التي تم إنشاؤها ، 5-10 ساعات في الأسبوع على الطائرات الشراعية). تم تصميم هذه العمليات للأشخاص الذين بدأوا البرمجة قبل شهر.

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

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

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

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

في نهاية المطاف ، تعد Agile (كما تمارس) و Waterfall شكلين من أشكال التنمية الموجهة نحو الأعمال ، وبالتالي ، لا يوجد أي منها مناسب لتطوير برامج عالية الجودة أو تحفيز الموظفين.

2. وضع المرؤوس من الشباب.

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

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

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

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

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

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

3. نهج قصير المدى ، وهو أمر غبي وخطير.

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

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

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

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

4. ليس له علاقة ببناء مهنة.

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

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

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

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

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

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

حقيقة الملاحظة تغير طريقة عمل الناس. في المجالات الإبداعية ، يؤلم. يكاد يكون من المستحيل العمل بشكل إبداعي إذا كنت بحاجة إلى الإبلاغ عن العمل كل يوم.

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

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

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

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

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

6. تأثير السكران.

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

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .