ما هو تأثير ITIL أو CMMI على التطوير؟ [مغلق

Question

قرأت الكثير من الكتب حول الممارسات التي تعمل بشكل جيد أو لا في تطوير البرمجيات. ولم أسمع قط عن Methodoly مثل ITIL أو CMMI في أي بث عبر الإنترنت أو كتاب أو مدونات في مجال التطوير.

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

ومع ذلك ، كل كتب عن التطوير قرأت الحديث عن التعاون ، أو الأشخاص على الوثائق. (نعم ، الكثير من الكتب الرشيقة)

لذا فإن سؤالي هو: هل المنهجيات مثل ITIL أو CMMI لها بعض التأثير أو العلاقة مع التطور أو الحياة اليومية للمطور؟ وهل لديك كتب أو مدونات رائعة تتحدث عن بعض الأفكار الجيدة في هذه metodologies التي يمكنني استخدامها في فريق التطوير؟

Answer 1

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

لقد عملت مع CMMI وعملية برمجيات الفريق (TSP) ، وكلا منتجات Watts Humphrey ومعهد Carnegie Mellon للبرمجيات. إذا كنت ملتزمًا بالتحسين المستمر وتعتقد أن القياس في قلب أي تحسين مستمر ، فستجد قيمة في CMMI.

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

التركيز على تتبع الوقت (اللكم على مدار الساعة) ، وتتبع العيوب (حصص الأخطاء) ، وخطوط التعليمات البرمجية (الكثير من الطرق "للعبة" حرية الابتكار) إيقاف العديد من المطورين. <-لاحظ الحجج المضادة المتواضعة بين قوسين.

تظل الحقيقة أن 90 ٪ من المطورين هناك (قليلون يقرأون StackOverflow أو أي مدونات/مواقع ويب تقنية) يطلقون النار من الورك ويفتقرون بشدة إلى الوعي الذاتي بمكان وجود فرصهم لتحسين. بالنسبة لهم ، فإن الدقة والفرصة لإجراء تحسينات تدريجية في الجودة من خلال الوعي الذاتي بأن التكرار والقياس يسهلون هما مكونات قيمة لـ CMMI.

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

Agile مثير و CMMI هو بعيد عن مثير بقدر ما يمكنك الحصول عليه ، وهذا هو السبب في أنك لا تسمع عنها بنفس القدر.

Answer 2

يميل التبني الرشيق إلى أن يكون من أسفل إلى أعلى: تعثر التقنيين عليه ويوصيونه بالإدارة.

تميل ITIL/CMMI إلى أن تكون من أعلى إلى أسفل: الإدارة تتعثر عليها وتدفعها إلى التقنيين.

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

Google لـ "Agile CMMI" وستحصل على العديد من الزيارات. أنا أفضل ألا أوصي بواحد على وجه الخصوص ، لأنه نقاش مستمر (أي أن بعض هؤلاء الأشخاص مخطئون للغاية).

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

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