من أحد المترجمين: هذا هو دليل DIB: Detectioning Agile BS (الإصدار 0.4) ، الذي نشرته لجنة الابتكار التابعة لوزارة الدفاع الأمريكية (DIB) للجمهور في 9 أكتوبر 2018.Agile هي كلمة طنانة في تطوير البرمجيات ، لذلك أصبحت جميع مشاريع برامج وزارة الدفاع الآن "مرنة" تقريبًا بشكل افتراضي. ستساعد هذه الوثيقة مديري البرامج والمتخصصين في وزارة الدفاع على التمييز بين مشاريع البرمجيات بمنهجية مرنة حقًا عن المشروعات التي تستخدم ببساطة "الشلال" أو "الحلزوني" ("رشيقة - سقوط سكروم") تحت ستار Agile.
المبادئ والقيم والأدوات
يحدد خبراء ومتحمسون أجيل المقاييس الأساسية التي تميز هذه الثقافة ونهج التنمية رشيقة. في أعماله ، طوّر DIB إرشاداته الخاصة التي تعكس تقريبًا قيم Agile الحقيقية:
| رشيقة القيمة | مبدأ DIB |
|---|
| الأفراد والتفاعلات أكثر أهمية من العمليات والأدوات | "الكفاءة أكثر أهمية من العملية" |
| تشغيل البرنامج أكثر أهمية من التوثيق الكامل | "تقليل الوقت من بداية المشروع إلى نشر أبسط الوظائف الأساسية" |
| التعاون مع العميل للاتفاق على العقد | "تنفيذ ثقافة DevSecOps لأنظمة البرمجيات" |
| الاستجابة للتغيير على الخطة | "يجب أن تبدأ البرامج صغيرة ، وتكون متكررة ، وتستفيد من النجاح - أو يتم التراجع عنها بسرعة". |
علامات رئيسية على أن المشروع غير مرن للغاية:
- لا يتواصل أي من فريق التطوير مع المستخدمين أو يتتبع البرامج أثناء العمل ؛ نعني المستخدمين الحقيقيين للرمز الحقيقي . (لا يُعتبر قسم تقييم البرنامج مستخدمًا حقيقيًا ، تمامًا مثل المسؤول الأول ، ما لم يستخدم البرنامج في عمله). البدائل المقبولة للتواصل مع المستخدمين: مراقبة عملهم ، ونقل النماذج الأولية إليهم للحصول على الملاحظات وطرق البحث الأخرى التي لا تنطوي على الكثير من التواصل اللفظي.
- لا توجد تعليقات مستمرة من المستخدمين لفريق التطوير (تقارير الأخطاء ، والتقييمات). لا يكفي التحدث مرة واحدة في بداية المشروع للتحقق من المتطلبات!
- يعتبر الامتثال أكثر أهمية من الحصول على أقل نتيجة مفيدة في أسرع وقت ممكن.
- أصحاب المصلحة (التطوير ، الاختبار ، DevOps ، الأمن ، المقاولون ، المستخدمون النهائيون ، إلخ.) يعملون بشكل أو بآخر بشكل مستقل (على سبيل المثال ، "هذا ليس من أعمالي").
- لا يشارك المستخدمون النهائيون في التطوير ؛ كحد أدنى ، يجب أن تكون موجودة أثناء تخطيط الإصدار واختبار القبول.
- ثقافة DevSecOps غير كافية عندما يتم تنفيذ العمليات التي يمكن ويجب أن تكون آلية تلقائيًا (على سبيل المثال ، الاختبار ، التكامل المستمر ، التسليم المستمر).
بعض أدوات تطوير رشيقة نموذجية (أنها تتغير كما
مظهر الأفضل):
- يعد Git أو ClearCase أو Subversion نظامًا للتحكم في الإصدار لتتبع التغييرات في التعليمات البرمجية المصدر. جيت هو المعيار الفعلي في التنمية الحديثة.
- BitBucket أو GitHub - مستودعات الاستضافة. كما أنه يتتبع التذاكر ولديه "تطبيقات" للتكامل المستمر وأدوات أخرى لتحسين الإنتاجية. تستخدم على نطاق واسع من قبل مجتمع المصادر المفتوحة.
- Jenkins أو Circle CI أو Travis CI هي خدمة تكامل مستمرة لبناء واختبار مشروعات Bitbucket و GitHub.
- برنامج Chef أو Ansible أو Puppet - برنامج لإنشاء "وصفات" لمهام تكوين التكوين والبث ودعم عدد من الخوادم.
- Docker هو برنامج كمبيوتر يقوم بإجراء المحاكاة الافتراضية على مستوى نظام التشغيل ، المعروف أيضًا باسم حاويات.
- Kubernetes أو Docker Swarm لتنسيق الحاويات.
- جيرا أو Pivotal Tracker - التذاكر والمراقبة والإدارة.
النسخة الرسومية:
أسئلة للمطورين
- كيف يمكنك اختبار الرمز؟ (إجابات خاطئة: "لدينا مؤسسة خاصة للاختبار" ، "قسم الاختبار وتقييم المنتج مسؤول عن الاختبار")
- الإصدار الموسع: ما هي مجموعة الأدوات التي تستخدمها في اختبارات الوحدة ، واختبار الانحدار ، والاختبارات الوظيفية ، ومسح الأمان ، وشهادة النشر؟
- ما مدى آلية تطوير خطوط الأنابيب والاختبار والأمن ونشرها؟
- الإصدار الموسع: ما هي مجموعة الأدوات التي تستخدمها للتكامل المستمر (CI) ، التسليم المستمر (CD) ، اختبار الانحدار ، وثائق البرنامج ؛ هل تعتمد البنية الأساسية على رمز؟
- من هم مستخدميك وكيف تتفاعل معهم؟
- نسخة موسعة: ما هي الآليات التي تستخدمها للحصول على ردود فعل مباشرة من المستخدمين؟ ما مجموعة الأدوات التي تستخدمها لإنشاء تقارير الأخطاء وتتبع التذاكر؟ كيف يمكنك توزيع علة إصلاح العمل بين الفرق؟ كيف يمكنك إعلام المستخدمين بأن مشكلاتهم يتم حلها و / أو حلها بالفعل؟
- ما هو الموعد النهائي لدورات الإصدار الحالية والمستقبلية؟
- نسخة ممتدة: ما هي منصات البرمجيات التي تدعمها؟ هل تستخدم الحاويات؟ ما هي أدوات إدارة التكوين الخاصة بك؟
أسئلة لمديري المشاريع
- كم عدد المبرمجين الذين هم جزء من المنظمة التي تخصص الميزانية ، وما هي المراحل الرئيسية للبرنامج؟ (إجابات خاطئة: "نحن لا نعرف" ، "صفر" ، "يعتمد ذلك على تعريف مبرمج")
- ما هي مقاييس الإدارة للتنمية والتشغيل ؛ كيف يتم استخدامها للتواصل مع الأولويات وتحديد المشكلات ؛ كم مرة يقومون بعرض واستخدام الدليل؟
- ما الذي تعلمته في آخر ثلاثة سباقات وكيفية تطبيق المعرفة الجديدة؟ (إجابات خاطئة: "ما هي العدو؟" ، "نحن في انتظار موافقة القيادة")
- من هم المستخدمون الذين يستفيدون من كل دورة سباق؟ هل استطيع التحدث اليهم (إجابات خاطئة: "نحن لا ننشر الكود مباشرة للمستخدمين")
أسئلة للعملاء والمستخدمين
- كيف تتواصل مع المطورين؟ هل يشرفون على عملك ويطرحون أسئلة ذات صلة تشير إلى فهم عميق لاحتياجاتك؟ متى كانت آخر مرة جلسوا فيها وناقشوا الميزات التي ترغب في رؤيتها؟
- كيف يمكنني تقديم اقتراحات لميزات جديدة أو الإبلاغ عن مشاكل أو أخطاء في التعليمات البرمجية؟ ما هي ردود الفعل التي تتلقاها بخصوص استفساراتك / تقاريرك؟ هل طُلب منك تجربة نماذج أولية لميزات البرامج الجديدة وشاهدت كيف تستخدمها؟
- كم من الوقت يستغرق تنفيذ الوظيفة المطلوبة في التطبيق؟
أسئلة للتوجيه
- هل يتم تسليم نسخة صالحة من البرنامج إلى عينة صغيرة على الأقل من المستخدمين الحقيقيين في كل تكرار (بما في ذلك الأول) ويتم تجميع المراجعات؟ (تلميح: كل أسبوعين)
- هل هناك ميثاق المنتج الذي يحدد المهمة والأهداف الاستراتيجية؟ هل يفهم جميع أعضاء الفريق كلاهما؟ هل يرون كيف يسهم عملهم في تحقيق الأهداف؟
- هل تتحول مراجعات المستخدمين إلى مهام محددة لفرق السباق مع مهلة زمنية أقل من شهر؟
- هل الفرق مخولة بتغيير المتطلبات بناءً على ملاحظات المستخدم؟
- هل للفرق الحق في تغيير عمليتها بناءً على ما تعلموه أثناء التطوير؟
- هل النظام البيئي بأكمله لمشروعك مرن؟ (إذا كانت التنمية الرشيقة تتبعها عملية تنفيذ خطية وبيروقراطية ، فهذا فشل).
بالنسبة لفرق Agile ، يجب أن تكون الإجابة على كل هذه الأسئلة هي نعم.
النسخة الرسومية:
توجد معلومات أكثر تفصيلاً عن بعض وظائف برامج وزارة الدفاع في الملحق أ (
متطلبات البرامج العشر ) ، الملحق ب (
مقاييس تطوير البرمجيات ) والتذييل جيم (أخطاء البرنامج وقواعده [سيتم إضافة الرابط لاحقًا] )