"كل شيء السم ، كل شيء دواء ، كلاهما يتحدد بالجرعة ".
باراسيلسوس
من المعتاد عد تاريخ
Agile من فبراير 2001 ، عندما ولدت وثيقة غريبة نوعًا ما -
Agile Manifesto . بشكل عام ، يتكون نص الوثيقة من أدلة فلسفية (على سبيل المثال ، "البساطة - فن عدم القيام بالكثير من العمل") والبيانات المثيرة للجدل (على سبيل المثال ، "يتم الحصول على أفضل المتطلبات التقنية والتصميم والهندسة المعمارية من فريق منظم ذاتيًا"). لكن هذه الوثيقة غريبة ليس كثيرًا في محتواها (أنت لا تعرف أبدًا ما قد يتبادر إلى الذهن في منتجع تزلج) ، ولكن في الطبيعة الملحمية للتغييرات اللاحقة في صناعة تطوير البرمجيات. في أقصر وقت ، ظهرت الكثير من التقنيات التي تنفذ منهجية التطوير "المرنة" ، التي تسير رسميًا في جميع أنحاء العالم ، وتأسر عقول المقاولين ومحافظ العملاء. يقدم الأتباع هذه الحركة كنوع من الأقراص السحرية التي تقرر كل شيء. لقد وصل الأمر إلى أن
المانح النبيل والمبرمج النزيه أصبح غير لائق بالفعل للاعتراف بالمشاركة في تطوير البرمجيات وفقًا
للتوجه التقليدي للمنهجية. دعونا نحاول أن نفهم أسباب وعواقب هذه الظاهرة ، باستخدام
سكروم كأكثر مظاهر رشيقة.
أولاً ، دعنا نحاول فهم ما هو جديد حقًا حصلنا عليه في غلاف Agile بشكل عام و Scrum بشكل خاص.
سكروم في مصر القديمة
سآخذ الحرية للتأكيد على وجود منهجية مرنة بشكل عام ، ومنهجية سكروم بشكل خاص ، على الرغم من أنهما لم يتم تسميتهما. لم يتم الاتصال بهم على الإطلاق ، ولكنهم ببساطة أكثر الطرق الطبيعية والفعالة لإجراء مشاريعهم الداخلية (الكلمة الرئيسية هنا هي "داخلية").
على سبيل المثال ، خطط الفرعون المصري القديم لبناء هرم و ... بدأ. ناقش الفكرة مع الكهنة (أصحاب المصلحة) وكلف خادمه بالمسؤولية عن المشروع (صاحب المنتج). وجد الكاتب عامل بناء مختص. استأجر مساعدو البناء (فريق سكروم) ، وذهبوا إلى سوق العبيد وسجلوا الرقيق (أدوات العمل: الكمبيوتر الشخصي ، الخادم ، برنامج التطوير ، إلخ).
منذ أن أمر الفرعون بتقرير شهري له عن تقدم البناء ، بدأ الماسون (مع المساعدين) في إجراء مظاهرة بناء شهرية (تجريبي) للخادم. خلال العرض ، لم تتم مناقشة ما تم القيام به بالفعل (بأثر رجعي) فحسب ، بل تم أيضًا وضع خطة للشهر التالي (سباق). من أجل عدم تفويت أي شيء ، ناقش حامل الكأس قصص المستخدم مع الكهنة لمدة شهر وكتبها في رق خاص (تراكم) ، سقطت منه قائمة الأمنيات في الخطة للشهر التالي. حسنا وهلم جرا. أنا لا أعرف ما تبدو عليه الملصقات ولوحة Scrum والرسوم البيانية المحترقة في ذلك الوقت. يختار أي قائد كفؤ الأدوات الأكثر ملاءمة لإدارة ومراقبة المشروع. التفاصيل ليست مهمة هنا ، الشيء الرئيسي هو أن التقنية تعمل.
على سبيل المثال أعتقد أن جميع المديرين في جميع الأوقات استخدموا تقنية مرنة لإنشاء منتجهم الداخلي (على مسؤوليتهم ومخاطرتهم) للأسباب التالية:
- المختصة بما يكفي لتصميم النتيجة النهائية ؛
- المختصة بما يكفي للسيطرة على العملية ؛
- امتلاك قوة كافية على المشاركين في العملية الثانوية ؛
- نسبة المصطلح والتكلفة وجودة العمل ليست عقيدة بالنسبة لهم ويمكن مراجعتها إذا لزم الأمر (حيث "هو سيده") ؛
- والأهم من ذلك ، أن كل من النتيجة النهائية وعملية تحقيقها هي في يد واحدة وتتابع مصلحة تجارية واحدة.
ولكن بالنسبة للعميل الخارجي ، لا ينطبق أي من العناصر في هذه القائمة ؛ وبالتالي ، بالنسبة للمشاريع الخارجية (المخصصة) ، لم يتم استخدام تقنية مرنة أبدًا (تؤكد الاستثناءات القاعدة فقط). بعد كل شيء ، كان الناس بسيطين وغير متسامحين ، من أجل زيادة صارخة للمواعيد النهائية والتقديرات ، كان بإمكانهم تقصير رؤوسهم.
سكروم في الوقت الحاضر
الجديد الوحيد في سكروم الحديث هو حقيقة استخدامه لتنفيذ المشاريع الخارجية (المخصصة). محاولة عدم التمسك بهذا الجانب من المشكلة ، لأن سحب الخيط يمكن أن يبرز الدافع الحقيقي للمشاركين في السوق. في الواقع ، فإن المظهر الرشيق وجميع حجج سكروم هي دعاية خالصة لمصالح المقاول ، من أجل الحشمة ، المحجبة في إطار النضال من أجل كل الخير ضد كل السيئ. هذه هي عبقرية الحل ، والتي تسمح لنا بإقناع العميل بالتضحية بالنتيجة من أجل العملية!
إذن ، ما الذي يتغير إذا كان مالك المنتج موظفًا في شركة أخرى ، وليس شركة خاصة به؟ والفرق الرئيسي هو أن النتيجة النهائية وعملية تحقيقها هي الآن على جوانب مختلفة من "الحاجز" وكل طرف يسعى فقط لمصلحته التجارية الخاصة. النتيجة مهمة للعميل ، والعملية مهمة للمقاول. لا يمكن أن يكون الأمر خلاف ذلك - بعد كل شيء ، "لا شيء شخصي ، هذا مجرد عمل".
رشيقة مفيدة للاعبين في سوق تكنولوجيا المعلومات ، لأنها توفر لهم الفرصة:
- كسب المال من العملية وعدم تحمل المسؤولية عن النتيجة ؛
- خفض تكلفة موظفي الإدارة الأكفاء (إنهم مكلفون ، لكنك لا تحتاج إلى تصميم أي شيء الآن ولا تحتاج إلى كتابة المعارف التقليدية ، وتتحكم العملية الآن في مالك منتج العميل).
وبما أن هذا مربح ، أمام أعيننا مباشرة ، يمكن لفرق البرمجة مع العمود الفقري للمهنيين المؤهلين تأهيلا عاليا وعقليا النظام أن تتحول إلى مزارع من برامج التشفير المستأجرة من الوسط.
حاول أن تضع نفسك في مكان الشخص الذي يستأجر فريقًا من البنائين لإصلاح شقته ويحاول الحصول على شروط وتكلفة الإصلاحات من قائد الفريق ، واستجابة لذلك يسمع:
- نحن مبدعون ، لذلك سنعمل "كما هو" ، ولكنك تدفع مقابل كل ساعة عمل للفريق والمواد ؛
- لن نقوم بمشروع وخطة مشتركة ، وسوف نكتشف ذلك على طول الطريق (إذا ارتكبنا شيئًا خاطئًا ، فسوف نعيده في الوقت الذي دفعت مقابله ومواد إضافية) ؛
- سنعرض نتائج عملنا كل أسبوعين ونتحدث عن مشاكلنا ، ثم سنخطط معًا الأسبوعين التاليين.
من غير المحتمل أن يوافق أي شخص على مثل هذا العرض ، ويوافق عملاء موظفي تكنولوجيا المعلومات! هذا ما تفعله الدعاية التي تمنح الحياة!
ليس فقط العملاء مقتنعون بالموافقة على التواريخ والتكاليف التي لا يمكن التنبؤ بها ، ولكنهم أيضًا يحولون كل مسؤولية الفشل إليها. كقاعدة ، لا يسمح تأهيل العميل بإضفاء الطابع الرسمي على متطلبات النتيجة النهائية والتحكم في العملية باحتراف. لذلك ، يمكن دائمًا الخلط والتشتيت (في غياب المعارف التقليدية العامة) لحل العديد من القضايا الثانوية (التي تنشأ في الغالب بسبب نقص التخطيط على المدى الطويل).
عواقب العبادة الرشيقة
ألا تعتقد أن جودة منتجات البرمجيات تنخفض بما يتناسب مع التوزيع الواسع النطاق لـ Agile في الصناعة؟ من أين تأتي الجودة إذا تم شحذ العملية برمتها عن طريق حل المشاكل بأبسط وأسرع طريقة ممكنة؟ والتفكير في المستقبل ممنوع رسميًا بالمنهجية!
ألا تعتقد أن منتجات البرمجيات تتحول بشكل متزايد إلى "لحاف مرقع" عندما تفاجأ بملاحظة أن أقسامًا مختلفة من البرنامج نفسه يبدو أنها مصنوعة من أشخاص مختلفين تمامًا؟ وحتى على شاشة برنامج واحدة ، يمكن خلط أنماط التصميم المختلفة ، والأساليب المريحة المختلفة ، والخوارزميات المختلفة لعمل عناصر التحكم المماثلة. ولكن لا يوجد دليل للمعارف التقليدية والأناقة للمنتج ، لذلك فإن أي شخص أكثر دراية سوف يفعل ذلك! وموظفي ضمان الجودة ، مثل أي شخص آخر ، مقيد بالمواعيد النهائية للسباق.
ما كل هذا؟
من كل ما سبق ، قد يبدو أنني أكره رشيقة متحمسة. لكن هذا ليس على الإطلاق! ولم أحاول الإساءة لأي شخص! حاول فقط أن يوضح بشكل أوضح كلمات Paracelsus العظيمة التي تم وضعها في النقوش.
منهجية مرنة مناسبة تمامًا للمشاريع الداخلية الصغيرة وحتى المتوسطة الحجم. يقتصر حجم المشروع فقط على قدرة قائد معين على "عدم فقدان الغابة خلف الأشجار" ، أي القدرة على تذكر كل التفاصيل والنتيجة المرجوة دون تنظيمها "على الورق".
منهجية مرنة مناسبة بشكل محدود للمشاريع الخارجية. في هذه الحالة ، تنطبق نفس المتطلبات على مالك منتج العميل كما هو الحال مع مدير المشروع الداخلي ، أي يجب أن يكون هذا الشخص محترفًا حقيقيًا في تكنولوجيا المعلومات ، وليس سكرتيرًا يتحمل عبءًا مؤقتًا بدوام جزئي. يجب أن يكون قادرًا على التحقق من مؤهلات الفريق المعين والرصد المستمر لجودة المنتج الذي يتم تطويره. بالإضافة إلى ذلك ، يجب أن يسمح المنتج الجاري تطويره (في حالة القوة القاهرة) باستبدال فريق التطوير. فقط في هذه الحالة يمكننا أن نتوقع أنها لن تكون "مهينة ومؤلمة لسنوات تعيش بلا هدف".
كما ترون ، فإن Agile لها مكانها في الشمس ، ولكنها محدودة جدًا في مجال تطوير تكنولوجيا المعلومات التعاقدية. ماذا تفعل إذا كان مشروعك لا يندرج ضمن فئة Agile-المناسبة؟
ألا يبدو مريبًا بالنسبة لك أن منهجية مرنة لم تتجذر في أي مكان آخر غير تطوير برامج العقد؟ حسنًا ، لا يفعلون غواصات أو طائرات أو سيارات على سكروم. تعلمنا حكمة أسلافنا أنه حتى بيت الكلب العادي لا يمكن تجميعه بدون مرحلة تصميم (رسم بالقلم الرصاص مع الأبعاد) وإعداد ToR (قائمة المواد والأدوات). تم إنشاء كل ما تراه حوله (من البراز إلى سفينة الفضاء) وفقًا لـ
"شلال" قديم جيد. لماذا لا تفعل نفس الشيء؟ وتذكر - كل شيء سيكون على ما يرام!
ملاحظة
يعتمد كل ما قيل على خبرتي الشخصية الكبيرة (19 عامًا) في تطوير الويب التعاقدي باستخدام كل من النهج التقليدي (الشلال) والتقدمي (سكروم). كان الدافع لكتابة المقالة هو المعاناة الأخلاقية للتأمل في "معجزة التكنولوجيا المعادية" التالية ، التي تم تجميعها معًا بموجب عهود فرانكنشتاين العظيمة لشركة غربية محترمة.
