مشاركة عبر

توصيات لإضفاء الطابع الرسمي على تطوير البرامج وإدارتها

  • مقالة

ينطبق على توصية قائمة التحقق من التميز التشغيلي في Azure Well-Architected Framework:

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

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

استراتيجيات التصميم الرئيسية

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

معايير التخطيط الإنمائي

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

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

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

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

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

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

  • قصص المستخدم: توحيد قالب لقصص المستخدم. تأكد من أن كل قصة مستخدم هي وحدة عمل منفصلة، مكتوبة من منظور المستخدم النهائي. يجب أن يكون لقصص المستخدم المكتوبة جيدا الخصائص التالية:

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

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

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

    • الجهد المطلوب لقصة المستخدم قابل للاقتدار بدرجة عالية من الثقة. دون القدرة على الحصول على تقريب وثيق للساعات المطلوبة لقصة مستخدم معينة، سيكون التخطيط صعبا ويزداد احتمال فقدان المواعيد النهائية، مما قد يتسبب في آثار متتالية على العمل المخطط له آخر.

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

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

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

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

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

  • التقارير: توحيد التقارير لأصحاب المصلحة الذين يقدمون مقاييس مفيدة تركز على التغيير. يسمح لك التركيز على التغيير بتعقب تسريع المنتج وتباطؤه. يمكن أن تتضمن المقاييس المفيدة تغييرات في:

    • معدل النمو الشهري للتبني.

    • الأداء.

    • وقت التدريب.

    • تكرار الحوادث.

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

تسهيل Azure

Azure Boards هي خدمة مستندة إلى الويب تمكن الفرق من تخطيط العمل وتتبعه ومناقشته عبر عملية التطوير بأكملها. إنه مناسب تماما لممارسات التطوير المستندة إلى Agile.

GitHub Projects هي أداة إدارة مشاريع قابلة للتخصيص يمكنها تنظيم المشاريع والتكامل باستخدام المشكلات وطلبات السحب في GitHub.

قائمة التحقق من التميز التشغيلي

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من التميز التشغيلي