كيف تتلاءم البرامج الجاهزة مع التطوير السريع؟[مغلق]

Question

ربما لا يكون فهمي للتطوير الرشيق جيدًا كما ينبغي، ولكنني أشعر بالفضول حول كيفية قيام المطور الرشيق باستخدام البرامج الجاهزة (OTS) عندما تكون المتطلبات والمعرفة بما يجب أن يكون عليه النظام النهائي هي يتغير بالسرعة التي أفهمها (غالبًا بعد كل تكرار للتطوير).

---

أرى حالتين تهمني بشكل خاص:

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

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

---

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

أسئلتي هي:

1. كيف تتلاءم البرامج الجاهزة مع التطوير السريع؟
2. كيف يتعامل مدير Agile ومطور Agile مع هذه الحالات؟
3. ماذا تقول النماذج الرشيقة عن هذه الحالات؟

Answer 1

السيناريو 1:

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

السيناريو 2:

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

يقول Agile افعل كل ما هو منطقي واستبعد الأنشطة التي لا تضيف قيمة :) Agile ليس حلاً سحريًا. فقط 2 سنتي رشيقة :)

Answer 2

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

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

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

تذكر أن "الفتح" هو الجزء المهم، وغالبًا ما يروج البائع لحله على أنه مفتوح عندما لا يكون كذلك بالفعل.

Answer 3

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

لذلك فإن هذا يعني إعادة التخطيط مع الشركة لمعرفة ما إذا كانت لا تزال ترغب في المضي قدمًا في المتطلبات الأصلية بعد أن عرفت المزيد.

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

Answer 4

مناقشة ويكي C2: http://c2.com/cgi/wiki?BuyDontBuild