فريق البرمجة
| فريق البرمجة | |
|---|---|
| فرع من | فريق التطوير |
تعديل مصدري - تعديل  | |
-ar.svg)
فريق البرمجة هو فريق من الأشخاص الذين يقومون بتطوير أو صيانة برامج الكمبيوتر .[1] قد يتم تنظيمهم بطرق عديدة، ولكن فريق البرمجة المتقلب والفريق الرئيسي للمبرمجين كانوا هياكل مشتركة.[2]
وصف
[عدل]يتألف فريق البرمجة من أشخاص يقومون بتطوير برامج الكمبيوتر أو صيانتها .[3]
برمجة فرق العمل
[عدل]ويمكن تنظيم فرق البرمجة بطرق عديدة، ولكن فريقالبرمجة egoless (إقولس) و رئيس فريق مبرمج نوعان من الهياكل المشتركة التي تستخدم عادة.[2] تتضمن المحددات الرئيسية عند اختيار هيكل فريق البرمجة عادةً: الصعوبة والحجم والمدة والنمطية والموثوقية والوقت والتواصل الاجتماعي.
برمجة Egoless
[عدل]وفقًا لمارلين مانتي، أفاد الأفراد الذين يمثلون جزءًا من فريق البرمجة اللامركزية عن ارتفاع الرضا الوظيفي.[2] لكن فريق البرمجة غير الأناني يحتوي على مجموعات من عشرة مبرمجين أو أقل. يتم تبادل الرمز وتحديد الأهداف بين أعضاء المجموعة. يتم تناوب القيادة داخل المجموعة وفقًا للاحتياجات والقدرات المطلوبة خلال وقت محدد. يمكن أن يؤدي نقص الهيكل في فريق egoless(إقلوس)إلى ضعف الكفاءة والفعالية واكتشاف الأخطاء للمشاريع واسعة النطاق. تعمل فرق البرمجة Egoless(إقلوس)بشكل أفضل للمهام المعقدة للغاية.
رئيس فريق المبرمجين
[عدل]عادة ما يحتوي فريق المبرمجين الرئيسيين على فرق مكونة من ثلاثة أشخاص تتكون من مبرمج رئيسي ومبرمج رفيع المستوى وأمين مكتبة البرنامج. يتم إضافة مبرمجين ومحللين إضافيين إلى الفريق عند الضرورة. تشمل نقاط الضعف في هذا الهيكل نقص التواصل بين أعضاء الفريق، والتعاون في المهام، وإكمال المهام المعقدة. يعمل فريق المبرمجين الرئيسيين بشكل أفضل للمهام الأبسط والمباشرة لأن تدفق المعلومات في الفريق محدود. عادة ما يبلغ الأفراد الذين يعملون في هيكل الفريق هذا عن انخفاض معنويات العمل.[2]
فرق محطة العمل المشتركة
[عدل]تقنية تطوير حيث يعمل مبرمجان معًا في محطة عمل واحدة.
برمجة الغوغاء
[عدل]نهج تطوير البرمجيات حيث يعمل الفريق بأكمله على نفس الشيء وفي نفس الوقت وفي نفس المكان وعلى نفس الكمبيوتر.
نماذج البرمجة
[عدل]تتيح نماذج البرمجة لفرق تطوير البرمجيات تطوير ونشر واختبار المشاريع باستخدام هذه المنهجيات المختلفة.
نموذج الشلال
[عدل]يعتبر نموذج الشلال، الذي يُشار إليه على أنه النهج التقليدي [4] ، نموذجًا خطيًا للإنتاج. فيما يلي تسلسل أحداث هذه المنهجية:
- جمع وتوثيق المتطلبات
- التصميم
- اختبار الكود والوحدة
- قم بإجراء اختبار النظام
- إجراء اختبار قبول المستخدم (UAT)
- أصلح أي مشاكل
- تسليم المنتج النهائي
تختلف كل مرحلة أثناء عملية تطوير البرنامج، وتنتهي كل مرحلة بشكل عام قبل أن تبدأ المرحلة التالية.
تستطيع فرق البرمجة التي تستخدم هذا النموذج تصميم المشروع في وقت مبكر في عملية التطوير مما يسمح للفرق بالتركيز على الترميز والاختبار أثناء معظم العمل بدلاً من تكرار التصميم باستمرار. يسمح هذا أيضًا للفرق بالتصميم بالكامل وبعناية أكبر بحيث يمكن للفرق الحصول على فهم كامل لجميع مخرجات البرامج.
إن نموذج التطوير الرشيق هو نهج تنمية قائم على الفريق أكثر [4] من نموذج الشلال السابق. تعمل الفرق في التسليم / النشر السريع الذي يقسم العمل إلى مراحل تسمى «العدو السريع». عادة ما يتم تعريف Sprints (سبرينت) على أنها أسبوعان من مخرجات البرامج المخططة المقدمة لكل فريق / عضو في الفريق.
بعد كل sprint (سبرينت) ، يتم إعادة ترتيب أولويات العمل ويتم استخدام المعلومات المستفادة من العدو السابق لتخطيط العدو في المستقبل. مع اكتمال عمل العدو، يمكن مراجعته وتقييمه من قبل فريق البرمجة وإرساله مرة أخرى لتكرار آخر (أي الركض التالي) أو إغلاقه إذا اكتمل.
المبادئ العامة [5] للبيان الرشيق [6] هي كما يلي:
- إرضاء العميل وتطوير البرامج باستمرار.
- يتم احتضان متطلبات التغيير من أجل الميزة التنافسية للعميل.
- ركز على تقديم برامج العمل بشكل متكرر. سيتم وضع تفضيل التسليم في أقصر فترة زمنية ممكنة.
- يجب على المطورين ورجال الأعمال العمل معًا طوال المشروع بأكمله.
- يجب أن تستند المشاريع إلى الأشخاص الذين لديهم الحافز. وفر لهم البيئة المناسبة والدعم الذي يحتاجون إليه. يجب الوثوق بهم لإنجاز وظائفهم.
- التواصل وجهًا لوجه هو أفضل طريقة لنقل المعلومات من وإلى الفريق.
- برنامج العمل هو المقياس الأساسي للتقدم.
- العمليات الرشيقة ستعزز التنمية المستدامة. يجب أن يتمكن الرعاة والمطورون والمستخدمون من الحفاظ على وتيرة غير محددة وثابتة.
- الاهتمام المستمر بالتميز التقني والتصميم الجيد سيعزز خفة الحركة.
- تعتبر البساطة فن تعظيم العمل الذي لم يتم، وهو ضروري.
- عادة ما تصنع الفرق ذاتية التنظيم أفضل التصاميم.
- على فترات منتظمة، سينظر الفريق في كيفية أن يصبح أكثر فعالية، وسوف يضبطون سلوكهم ويعدلونه وفقًا لذلك.
انظر أيضا
[عدل]- فريق متداخل الوظائف
- سكروم (تطوير البرمجيات)
- عملية تطوير البرمجيات
- عملية برمجيات الفريق
المراجع
[عدل]- ^ Jack Belzer, Albert George Holzman, ألين كينت (1 أكتوبر 1979)، Encyclopedia of computer science and technology، ج. 13، مؤرشف من الأصل في 2020-04-11
{{استشهاد}}: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) - ^ ا ب ج د Marilyn Mantei (مارس 1981). "The Effect of Programming Team Structures on Programming Tasks" (PDF). ج. 24 رقم 3. مؤرشف من الأصل (PDF) في 2020-04-11. اطلع عليه بتاريخ 2019-03-26.
{{استشهاد بمجلة}}: الاستشهاد ب$1 يطلب|$2=(مساعدة)صيانة الاستشهاد: أسماء عددية: قائمة المؤلفين (link) صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) صيانة الاستشهاد: علامات ترقيم زائدة (link) - ^ Jack Belzer, Albert George Holzman, ألين كينت، Encyclopedia of computer science and technology، ج. 13، مؤرشف من الأصل في 2020-04-11
{{استشهاد}}: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) - ^ ا ب Mary Lotz (5 يوليو 2018)، Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?، مؤرشف من الأصل في 2020-04-11
- ^ Linchpin SEO Team (26 مارس 2019)، A Beginners Guide To The Agile Method & Scrums، مؤرشف من الأصل في 2020-04-11
- ^ "Principles behind the Agile Manifesto". 11 يونيو 2019. مؤرشف من الأصل في 2020-04-11.
