عندما تم تطوير البرنامج لأول مرة ، لم تكن عملية التطوير مناسبة لأي نوع من الحوكمة. ثم جاء الشلال الذي قدم فكرة أن تطوير البرامج يمكن تحديده في الوقت الذي يتم فيه إنشاء التطبيق أو إنشائه.
لقد كان الأمر يستغرق وقتًا أطول بكثير لاختبار ونشر البرامج أكثر مما هو عليه الآن لأنه لم يكن هناك توازن ولا قيود خلال عملية التطوير. نتيجة لذلك ، تلقينا برنامجًا ذا جودة منخفضة به أخطاء وأخطاء ، تم إجراؤه بعد المواعيد النهائية المحددة بكثير. كان التركيز على تخطيط المشروع الطويل والمطول.
تم ربط تصميمات الشلال بنموذج القيد الثلاثي، ويسمى أيضًا مثلث إدارة المشروع. كل جانب من المثلث يمثل أحد المعوقات إدارة المشاريع: نطاق ، الوقت، و التكلفة . كما كتب أنجيلو بيريتا ، ينص نموذج القيد الثلاثي على أن "التكلفة هي دالة للوقت والحجم ، وهذه العوامل الثلاثة مرتبطة بطريقة معينة ويمكن التنبؤ بها ... إذا أردنا تقصير المهلة (الوقت) ، يجب علينا زيادة التكلفة. يشير النموذج أيضًا إلى أنه إذا أردنا زيادة الحجم ، فيجب علينا زيادة التكلفة أو المهلة ".
الانتقال من الشلال إلى الرشيق
جاء الشلال إلينا من الإنتاج والهندسة الميكانيكية ، والتي يصعب تخيلها بدون عملية خطية. قبل أن تبني سقفًا ، عليك أن تبني الجدران. كما تم النظر إلى مشاكل تطوير البرمجيات على أنها شيء يمكن حله من خلال التخطيط.
في النهاية ، تم التعرف على الشلال باعتباره نهجًا ضارًا ، على عكس النهج البديهي لتطوير البرامج. في كثير من الأحيان لا يمكن تحديد قيمة المشروع حتى نهاية دورة المشروع. في كثير من الحالات ، فشلت المشاريع. بالإضافة إلى ذلك ، لم ير العميل أي برنامج يعمل حتى نهاية المشروع.
يتضمن Agile نهجًا مختلفًا يبتعد عن تخطيط المشروع بأكمله ، وربطه بالتواريخ والتقارير المقدرة. تفترض منهجية Agile عدم اليقين وتأخذ في الاعتبار. يشجعك على الرد على التغيير بدلاً من تجاهله. يُنظر إلى التغيير على أنه وسيلة لتلبية احتياجات العملاء.
قيم رشيقة
يخضع Agile للبيان Agile. فيما يلي مبادئه الـ 12 :
- رضا العملاء هو الأولوية القصوى.
- يتم تشجيع تغيير المتطلبات ، حتى في المراحل اللاحقة من التطوير.
- يجب إطلاق منتج عامل بقدر الإمكان.
- يجب على المطورين وممثلي الأعمال العمل معًا.
- يجب أن يعمل المحترفون المتحمسون في المشروع.
- التواصل المباشر هو الطريقة الأكثر عملية وفعالية لتبادل المعلومات.
- منتج العمل هو المؤشر الرئيسي للتقدم.
- تساهم العمليات الرشيقة في التنمية المستدامة.
- من المهم الانتباه إلى التميز التقني والتصميم الجيد.
- البساطة ضرورية.
- تأتي أفضل الحلول المعمارية والمتطلبات وأفكار التصميم من فرق ذاتية التنظيم.
- فكر بانتظام في طرق تحسين الأداء وتعديل أسلوب عملك.
4 أفكار رئيسية لـ Agile:
- الناس والتفاعل أكثر أهمية من العمليات والأدوات ،
- المنتج العامل أهم من التوثيق الشامل ،
- التعاون مع العميل أهم من الاتفاق على شروط العقد ،
- أن تكون على استعداد للتغيير أكثر أهمية من اتباع الخطة الأصلية.
هذا النهج مختلف تمامًا عن الشلال الصلب. في Agile ، العميل هو عضو في فريق التطوير. في الشلال ، يشارك فقط في البداية ، عند تحديد متطلبات العمل ، وفي النهاية ، عند التفكير في المنتج النهائي. في Agile ، يساعد العميل الفريق في كتابة معايير قبول المنتج ويظل مشاركًا طوال العملية. بالإضافة إلى ذلك ، يتطلب Agile التغيير والتحسين المستمر من جميع أعضاء المنظمة. يعمل فريق التطوير مع فرق أخرى بما في ذلك مديري المشاريع والمختبرين. يعتمد من يفعل ماذا ومتى على الدور المعين ويتم مناقشته مع الفريق بأكمله.
تطوير البرمجيات رشيق
يتطلب تطوير البرمجيات الرشيقة التخطيط التكيفي والتصميم التطوري وتسليم المنتج النهائي. يتم تصنيف العديد من منهجيات وهياكل وممارسات تطوير البرمجيات على أنها مرنة ، بما في ذلك:
- سكرم
- Kanban ( )
- XP ( )
- Lean
- DevOps
- FDD ( )
- TDD ( )
- Crystal
- DSDM ( )
- ASD ( )
يتم استخدامها جميعًا بمفردها أو بالاشتراك مع منهجيات أخرى لتطوير البرامج ونشرها. الأكثر شيوعًا هي Scrum و Kanban (أو مجموعة تسمى Scrumban) و DevOps.
Scrum هو إطار عمل يعمل فيه الفريق بشكل مستقل ومتشابك للوظائف لزيادة سرعة تسليم المنتج النهائي وإضافة قيمة إلى أعمال العميل. يتكون الفريق عادة من Scrum Master ومدير المنتج والمطورين. ينصب التركيز الرئيسي في Scrum على التكرارات الأسرع بتحسينات أقل .
كانبانهو إطار عمل رشيق ، والذي يشار إليه أحيانًا بنظام إدارة سير العمل. إنه يساعد الفريق على تصور عملهم وزيادة الكفاءة (مع الحفاظ على المرونة). كانبان عادة ما يكون سبورة بيضاء رقمية أو مادية. تنتقل مهام الفريق حول اللوحة اعتمادًا على المرحلة: لم تبدأ المهمة بعد ، قيد التقدم ، قيد الاختبار ، مكتملة. يسمح Kanban لكل عضو في الفريق برؤية حالة المهام.
قيم DevOps
DevOps هي ثقافة وطريقة في التفكير وطريقة لتطوير البرامج أو البنية التحتية وطريقة لبناء ونشر البرامج والتطبيقات. العمليات والتطوير ليست منفصلة. أنها تعمل في وقت واحد دون التدخل مع بعضها البعض
تعتمد DevOps على مجالين آخرين: Lean و Agile. DevOps ليس اسمًا أو دورًا في شركة. هذا في الواقع التزام تقوم به منظمة أو فريق فيما يتعلق بالتسليم المستمر للمنتج والنشر والتكامل. وفقًا لجين كيم ، مؤلف كتاب The Phoenix and The Unicorn Project ، هناك ثلاثة "مسارات" تحدد مبادئ DevOps:
- مبادئ التدفق ،
- مبادئ التغذية الراجعة ،
- مبادئ التعلم اللانهائي.
تطوير برامج DevOps
DevOps هي ممارسة رشيقة. في شكله الحقيقي ، يمثل ثقافة مشتركة وتفكيرًا حول تطوير البرمجيات وتنفيذ تكنولوجيا المعلومات أو البنية التحتية.
عندما تفكر في التشغيل الآلي والسحابة والخدمات المصغرة ، فإنك تفكر في DevOps.
كتب نيكول فورسغرين وجيز هامبل وجين كيم الكتاب عجلوا! كيفية بناء وتوسيع نطاق المنظمات عالية الأداء. " في مقابلة ، أوضحوا ما هو DevOps:
- تسليم البرامج الفعال مهم. لها تأثير كبير على الربحية وحصة السوق والجودة ورضا العملاء والأهداف والرسالة التنظيمية.
- الشركات ذات الكفاءة العالية تحقق سرعة تطوير عالية واستقرار وجودة. ليس عليهم التضحية بأي شيء لتحقيق كل هذا.
- يمكنك تحسين أدائك من خلال تطبيق مبادئ وممارسات DevOps من Lean، Agile.
- يؤثر تنفيذ هذه الممارسات والفرص أيضًا على ثقافتك التنظيمية. إنه ، بدوره ، يؤثر على كل من فعالية برنامجك وإنتاجية المؤسسة.
- يتطلب الأمر الكثير من العمل لمعرفة كيفية تحسين الكفاءة.
DevOps و Agile
على الرغم من أوجه التشابه ، فإن DevOps و Agile بعيدان عن نفس الشيء. يجادل البعض بأن DevOps أفضل من Agile. من المهم الوصول إلى الجزء السفلي منه لتجنب الالتباس.
التشابه
- كلاهما منهجيتان لتطوير البرمجيات ، لا يمكنك المجادلة في ذلك.
- كانت Agile موجودة منذ أكثر من 20 عامًا ، كما أن DevOps جديدة نسبيًا.
- كلا النهجين يؤمنان بالتطوير السريع للبرامج. تستند مبادئهم على كيفية تطوير البرامج بسرعة دون الإضرار بالعميل أو العمليات.
اختلافات
- , .
- , DevOps, Agile. , Agile , . DevOps, , , . .
- Agile , . DevOps , DevOps . , .
- DevOps , Agile . Agile MVP ( ) .
- Agile — , .
| Agile | DevOps |
|---|---|
| , | |
Agile و DevOps شيئان مختلفان ، على الرغم من أن أوجه التشابه بينهما دفعت الكثيرين إلى الاعتقاد بأنهما متماثلان. يؤدي سوء الفهم هذا إلى الإضرار بشركة Agile و DevOps.
لقد عملت في Agile ومن تجربتي يمكنني القول أنه من المهم جدًا للفرق والمؤسسات أن تفهم ماهية DevOps و Agile. تحتاج أيضًا إلى فهم كيفية مساعدة الفرق على العمل بشكل أسرع وأكثر كفاءة ، وضمان جودة المنتج ، وتحسين رضا العملاء.
Agile و DevOps لا يتنافسان بأي حال من الأحوال (على الأقل لا توجد أسباب حتى الآن). إنهم حلفاء وليسوا أعداء في المجال الرشيق. يمكن أن تعمل Agile و DevOps بطريقة حصرية وشاملة ، مما يسمح لها بالتواجد في نفس المساحة.
ترجمة: ديانا شيريميفا
تعرف على المزيد حول كيفية الحصول على مهنة رفيعة المستوى من الصفر أو Level Up في المهارات والراتب من خلال أخذ دورات SkillFactory المدفوعة عبر الإنترنت:
- دورة DevOps (12 شهرًا)
المزيد من الدورات
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )