هل تتناسب ITIL مع عالم رشيق؟ [مغلق

Question

يدفع مدير تكنولوجيا المعلومات لدينا إلى ITIL ، فأنا على دراية به بشكل فضفاض وأردت معرفة ما إذا كان ITIL يناسب دورة عمل رشيقة؟

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

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

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

ما الذي يختبره الآخرون مع أساليب ITIL وأرشييل العمل معًا؟

Answer 1

في شركتي ، يتم استخدام ITIL Framework لتقديم الخدمات (الإنتاج ودعم الحوادث). لأن هذه SLAs مناسبة كما لو كنت تقول إن فقدان العملاء/المال في الساعة ، ومن المتوقع أن يكون لدى الأعمال بعض الإشارة إلى موعد إصلاح الأمور. لا يرتبط مباشرة بمنهجية التنمية. فقط إذا قررت أن الإصلاح الساخن في حالات الطوارئ مطلوب وموافقة عليه ، فقد يتم إجراء بعض التطوير. لكن الإصلاحات الساخنة عادة ما تكون صغيرة جدًا وتستهدف لإصلاح العيب ولا ينبغي أن تسبب أي مشاكل في منهجية رشيقة. لا يتم إجراء المتطلبات الجديدة أبدًا كتغيير للإصلاح الساخن ويتم أخذها في عملية DEV/Test/REFICT العادية.

Answer 2

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

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

تحديث:

فهل ستقول أن عمليات التطوير العادية يمكن إعفاؤها من منهجيات ITIL وأن تركز ITIL بحتة على مناطق دعم البنية التحتية/الحوادث؟

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

يجب أن يتضمن التطوير اعتبارات في التصميم / المنتج المطلوبة من قبل التركيب / الدعم ، وهذه قد تتعلق بالممارسات المقترحة في ITIL.

ربما يكون السؤال الأكثر ملاءمة هو: هل تنطبق جوانب/ممارسات الإدارة في ITIL على إدارة تطوير البرمجيات؟ وهو ما لا أعرفه ، لكن المشتبه به موجه خصيصًا في ITIL. على الأقل أعلم أن ITIL 3 قدمت تغييرات تتعلق بممارسات الهندسة المعمارية للمؤسسات ، والتي تتوافق بالتأكيد مع Agile (في الواقع هي عوامل تمكين) --- ولكن على الأقل هذه بعيدة عن أي شيء يتعلق بالتقديرات الثابتة / تتبع المهام / استجابة DEV .