كيف أثبت لصاحب المصلحة والمدير أن برنامجي يعمل؟[مغلق]

Question

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

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

أنت بحاجة إلى تقديم برامج عالية الجودة في الوقت المحدد، وفي حدود الميزانية

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

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

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

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

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

والآن بالنسبة لسؤالي:

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

[أضيفت لاحقا]

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

سؤال المتابعة هو ما الذي يجب أن يتضمنه كل ذلك في سياسة ضمان الجودة؟

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

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

[أضيفت لاحقا]

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

لذا، فإن الطريقة الوحيدة التي يمكنني (الآن) تصورها لتمكين الثقة مع المختبرين هي:- تحدث مع فريق الاختبار الحالي، وراجع الاختبارات التي يمكنهم تنفيذها يدويًا (من نصوص الاختبار والسيناريوهات الخاصة بهم) وتأكد من أن فريقنا قد أجرى هذه الاختبارات باعتبارها اختبارات وحدة تم فحصها بالفعل مقابل خدمة الويب الخاصة بنا.سيكون ذلك بمثابة نقطة بداية جيدة لـ "تسجيل الخروج" قبل أن نقوم بإصدار إصدار يجب على فريق طبقة العرض التقديمي دمجه.سوف يستغرق الأمر بعض الجهد لتوضيح أن إنشاء اختبارات تلقائية لجميع هذه السيناريوهات سيستغرق بعض الوقت.ولكن سيكون من المفيد بالتأكيد التأكد من أن ما نبنيه يعمل بالفعل.

Answer 1

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

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

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

Answer 2

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

العميل، لا يسأل عن ذلك، لقد كان غاضبًا حقًا، لكنهم بقوا مع شركتنا لأنهم يعلمون أنه لا أحد يفهم العمل مثلنا.

لذلك ما هو الحل:

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

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

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

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

Answer 3

في جميع الحالات باستثناء الحالات التافهة، لا يمكنك "إثبات" صحة برنامجك.

هذا هو دور شسر أالقبول تإستينج:لإظهار أنه تم الوصول إلى مستوى مقبول من الفائدة.

Answer 4

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

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

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

Answer 5

وكما قال بيلي جويل ذات مرة، "لقد كانت دائمًا مسألة ثقة".

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

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

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

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

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