كيفية تشغيل عملية تطوير ناجحة (حتى لو لم تكن تقنية)

لن يكون ذلك greeeeeat ... (Office Office ، 1999)

صاغ لورنس بيتر مبدأ "رفع المديرين إلى مستوى عدم الكفاءة" في عام 1969. على وجه الخصوص ، اكتسب القادة غير التقنيين سمعة سيئة لدى مطوري البرمجيات.

يصور Office Space المدير غير الفني في Bill Lumbergh ، كما هو موضح أعلاه. يوفر Dilbert "Pointy-Haired Boss" الكلاسيكي.

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

أكبر درس تعلمته هو أن مفتاح الحفاظ على إصدارات البرامج الناجحة غير تقني تمامًا.

إنها عملية.

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

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

ماذا نبني

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

هل يجب علي استخدام هذه الخطط أم مجرد جناح لها؟ هم ... (المصدر)

يجب أن تتضمن خريطة الطريق الخاصة بك مجموعة من الخطط التي يحقق كل منها غرضًا مختلفًا. هذه الخطط تختلف عن التطبيقات الفردية. نموذج محاكاة واجهة المستخدم ورسم مخطط التطبيق ونموذج العمليات التجارية شائعان. غالبًا ما تكون المخططات التفصيلية للمكونات مثل مخططات لغة النمذجة الموحدة (UML) ونماذج التدفق مفيدة أيضًا.

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

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

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

ما لا للبناء

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

لماذا تبني هذا التطبيق في المقام الأول؟ تحديد التمايز الرئيسي عن المنتجات الحالية. يجب أن يذهب 80٪ من وقت فريقك نحو دعم هذا التمايز.

الخطط التي يجب أن يكون لديك الآن ستكون مفيدة هنا. هل يتضمن التطبيق الخاص بك مكون تسجيل؟ عملية التسجيل وتسجيل الدخول؟ هناك بالفعل أطر برامج مجانية مفتوحة المصدر (FOSS) في معظم اللغات لهذه المكونات. بعضها متاح بموجب تراخيص متساهلة للغاية.

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

في النهاية ، انتقلت تسلا إلى بناء بنى تحتية كاملة لدعم سياراتهم ، مثل محطة

أول نموذج أولي لـ Tesla حول سيارة رياضية كهربائية موجودة مسبقًا من بطاريات الرصاص الحمضية إلى بطاريات الليثيوم. كان أول إنتاج لها هو سيارة لوتس إليز رودستر (سيارة رياضية موجودة سابقًا) كانت تحتوي على بطارية ومحرك تسلا.

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

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

تتمثل نقطة التفتيش الثانية لعملية التطوير في مراجعة البنية المخطط لها مع فريقك وتحديد الجزء المحدود للغاية الذي يعتزمون إنشاؤه من البداية.

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

لا ترميه فقط على الحائط

في كثير من الأحيان ، تقوم فرق التطوير

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

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

إبقاء فريق دعم الإنتاج في الحلقة مبكراً هو 90٪ من الصلصة السرية المعروفة باسم "DevOps". إذا لم تكن قد سمعت بهذا ، فإن DevOps هي فكرة أن فرق تطوير البرمجيات وعمليات الإنتاج يجب أن تتحد في إطار الأهداف المشتركة.

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

التنفيذ والاختبار

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

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

قيادة فريقك في التوزيع العادل للعمل. تحدي الجميع على النمو بشكل مناسب والمشاركة والتعاون.

أحد الجوانب الفنية للتطبيق هو أن الكود يجب أن يتضمن اختبارات آلية كافية. هذه اختبارات معرفة بالكود يمكن لنظام اختبار تنفيذها.

إذا تعطلت الكود ، ألا تريد أن يكون هؤلاء الشباب على الخط بدلاً من أن يكونوا على عاتقك؟ (المجال العام: صورة حكومة الولايات المتحدة)

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

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

يشار إلى نقطة التفتيش التي يعتقد المطورين أنها أكملتها في متجري باسم dev-Complete. يعني ذلك أن عملية التطوير الأساسية (dev) قد انتهت ، ولكن قد تتم كتابة التعليمات البرمجية الإضافية لمعالجة المشكلات التي تطرأ في عملية المراجعة.

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

ارجع إلى خارطة الطريق التي حددتها في الخطوة الأولى. قبل بدء المكون (المكونات) الجديد ، تأكد من أن ما بدأته بالفعل على الأقل غير مكتمل. هذا يوفر لك رؤية دقيقة لسرعة التنمية ويقلل من المخاطر.

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

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

يمكن دمج التغذية المرتدة من اختبار القبول في التكرار التالي. هذا سبب وجيه آخر لعدم تعريض جزء كبير من المنتج دفعة واحدة. تريد أن تترك مجالًا لتغيير المسار بمجرد أن يبدأ الأشخاص باللعب مع المنتج.

بمجرد قيامك بتجميع ما يكفي من الشفرة المختبرة لتشكيل إصدار منتج كافٍ ، فأنت جاهز لبدء عملية إدارة الإصدار.

أبحث عن الأخطاء في جميع الأماكن الصحيحة

يجب أن يكون الخطأ هنا في مكان ما ... (المصدر)

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

قد لا تكون مرتاحًا أو لديك خبرة فنية كافية لمراجعة رمز الفريق بنفسك. هذا حسن! ليس لديك ل. عملية لديك ل.

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

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

في ختام عملية مراجعة الكود ، يجب أن يشعر المطور والمراجع (المراجع) بالراحة عند تحميلهم المسؤولية عن الكود.

تعد مراجعة الشفرة أيضًا وقتًا جيدًا لمراجعة نقطتين أساسيتين أخريين: الوثائق والأمان.

لقد كتبت بالفعل عن بنية مستدامة للوثائق - راجعها إذا كنت مهتمًا!

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

ينشر مشروع أمان تطبيق الويب المفتوح (OWASP) دليلًا مجانيًا مجانيًا لمراجعة الأمان.

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

إخراج ، إخراج ، إخراج!

اجتاز الرمز عملية المراجعة. إنها جاهزة لتصبح منتجًا. لكن هذا لا يعني أنه جاهز للإنتاج.

آخر نقطة تفتيش واضحة هي استعداد النشر. هل الشفرة في حالة يسهل نشرها للإنتاج؟ يجب أن يتضمن ذلك أقل عدد ممكن من الخطوات اليدوية.

هذا يعني أيضًا أنك بحاجة إلى خطة للتراجع عن التغيير في حالة عدم عمل الشفرة كما هو مخطط لها. وهذا ما يسمى "خطة التراجع".

ليس كل رمز الإنتاج يبقى في الإنتاج ... (المصدر)

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

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

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

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

بمجرد اجتياز نقطة التفتيش هذه ، ادفع هذا الرمز إلى الإنتاج!

الافراج عن بعد

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

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

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

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

قبل كل شيء ، مساءلة نفسك وفريقك عن نتائج جهدك.

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

استنتاج

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

مفتاح إصدار البرنامج الناجح هو عملية موثقة جيدًا ومدروسة جيدًا لنقل البرامج عبر خط الأنابيب من الفكرة إلى المنتج. لديك الآن نقطة انطلاق لصياغة عملية إصدار البرنامج الخاص بك.

الأمر الأكثر أهمية هو أنك تشارك مع فريقك في ملء الفراغات وإنشاء عملية قابلة للتكرار تناسبك جميعًا.

لا يجب أن تكون مثالية لأي شخص ، ولكن يجب أن يفهمها الجميع.

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

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

وتذكر أن فرشاة شعرك. لا تريد أن تبدو ... مدبب.

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

يمكنك أيضًا الاستمتاع بمقالاتي الأخرى حول العملية التجارية لتطوير البرمجيات:

  • ما تفتقده عن طريق تخطي قائمة التحقق
  • كيف أعدنا تنظيم أنفسنا في متجر تطوير أكثر احترافًا عندما فقدنا معلمنا الوحيد الذئب

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