gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

chore: remove guide (#36709)

Browse Source
This commit is contained in:
mrugesh
2019-08-29 00:23:22 +05:30
committed by GitHub
parent 50810c3ae3
commit f27bb5cc1b
27018 changed files with 0 additions and 997159 deletions
Download Patch File Download Diff File Expand all files Collapse all files

203
guide/arabic/accessibility/accessibility-basics/index.md
View File

@ -1,203 +0,0 @@
---
title: Accessibility Basics
localeTitle: أساسيات الوصول
---
> "الفنون المظلمة كثيرة ومتنوعة ومتغيرة باستمرار وأبدي. إن محاربتهم تشبه محاربة وحش كثير الرأس ، وفي كل مرة ينقطع عنق ، ينبت رأسه أكثر شراسة وأذكى من ذي قبل. وهو غير مثبت ، متحور ، غير قابل للتدمير ".
>
> \- الأستاذ سيفيروس سناب ، سلسلة هاري بوتر
إن دور إمكانية الوصول في التطوير هو في الأساس فهم منظور واحتياجات المستخدم ، ومعرفة أن الويب والتطبيقات هي حل للأشخاص ذوي الإعاقات.
في هذا اليوم وهذا العصر تم اختراع المزيد والمزيد من التقنيات الجديدة لجعل حياة المطورين وكذلك المستخدمين أسهل.
إلى أي درجة يعتبر هذا شيئًا جيدًا هو النقاش لفترة أخرى
في الوقت الحالي ، يكفي أن نقول أن صندوق أدوات المطور ، وخاصة مطور الويب ، يتغير باستمرار مثلما تسمى "الفنون السوداء" وفقًا لصديقنا سناب.
يجب أن تكون إحدى الأدوات في مربع الأدوات هذا هي إمكانية الوصول.
إنها أداة يجب استخدامها بشكل مثالي في واحدة من الخطوات الأولى لكتابة أي شكل من أشكال محتوى الويب ومع ذلك;فإن هذه الأداة ليست في الغالب مقدمة بشكل جيد في صندوق أدوات معظم المطورين.
قد يكون هذا بسبب حالة بسيطة من عدم معرفتها حتى للحالات المتطرفة مثل عدم الاهتمام بها
في حياتي كمستخدم وبعد ذلك مطور يستفيد من إمكانية الوصول في أي شكل من أشكال المحتوى.
رأيت طرفي هذا الطيف.
إذا كنت تقرأ هذا المقال ، فأنا أظن أنك في واحدة من الفئات التالية:
* أنت مطور ويب مبتدئ وترغب في معرفة المزيد حول إمكانية الوصول
* أنت مطور ويب محنك وفقدت طريقك (المزيد عن ذلك لاحقًا)
* تشعر أن هناك التزامًا قانونيًا من العمل ، وتحتاج إلى معرفة المزيد عنه.
إذا كنت خارج هذه الفئات العريضة ، فيرجى إبلاغي بذلك. أنا دائما أحب أن أسمع من الناس الذين يقرؤون ما أكتب عنه, يؤثر تنفيذ الوصول على الفريق بأكمله، من الألوان التي اختارها المصمم والنسخة التي يكتبها مؤلف الإعلانات وعليك المطور.
## إذن ، ما هي إمكانية الوصول على أي حال؟
تعتبر إمكانية الوصول في حد ذاتها عبارة عن مصطلح مضلل في بعض الأحيان ، خاصة إذا كانت اللغة الإنجليزية هي لغتك الثانية. يشار إليها أحيانا على أنها تصميم شامل.
إذا كان موقعك على الإنترنت ، يمكن الوصول إليه من قبل أي شخص لديه متصفح ويب، بمعنى أن موقع الويب متاح للجميع من خلال متصفح الويب.
ولكن هل كل المحتوى على موقع الويب الخاص بك مقروء بالفعل وقابل للاستخدام ومفهوم للجميع؟
أليست هناك عتبات تمنع بعض الأشخاص من "الوصول" إلى جميع المعلومات التي تعرضونها؟
يمكنك أن تسأل نفسك أسئلة مثل الأسئلة التالية:
* إذا قمت بإضافة معلومات موجودة فقط في ملف صوتي ، فهل يستطيع الشخص الأصم الحصول على هذه المعلومات؟
* إذا كنت تدل على جزء مهم من موقعك على الويب بلون معين ، فهل سيعرف شخص عملاق الألوان ذلك؟
* إذا أضفت صورًا على موقعك على الويب تنقل معلومات مهمة ، فكيف سيعرف الشخص المكفوف أو ضعيف الرؤية ذلك؟
* إذا كنت تريد التنقل في التطبيق باستخدام لوحة المفاتيح أو عصا الفم ، هل سيكون ذلك ممكنًا أم متوقعًا؟
* هل يفترض التطبيق الخاص بك اتجاه الجهاز وماذا لو لم يتمكن المستخدم من تغييره فعليًا؟
* هل هناك مظاهر متسامحة من التطبيق الخاص بك لشخص قد يحتاج إلى مزيد من الوقت لملء نموذج؟
* هل لا يزال تطبيقك يعمل (التحسين التدريجي) على افتراض أن JavaScript لا يتم تحميله في الوقت المناسب؟
* يمكنك حتى الذهاب إلى حد القول ، إذا كان موقع الويب الخاص بك ثقيلًا في الموارد ، فهل يتمكن شخص ما على اتصال بطيء أو متقطع من قراءة المحتوى الخاص بك؟
هذا هو المكان الذي يدخل حيز التشغيل. يستلزم الوصول بشكل أساسي جعل المحتوى الخاص بك ودودًا ، ويسهل الوصول إليه بأكبر قدر ممكن من الأشخاص. ويشمل ذلك الأشخاص الأصم ، ضعاف البصر ، المكفوفين ، المصابين بفرط الصوت ، البكم ، على الاتصال البطيء ، عمى الألوان ، يعانون من الصرع ، الإرهاق العقلي ، العمر ، القيود المادية ، إلخ.
## لماذا تنفيذ الوصول؟
قد تعتقد أن إمكانية الوصول لا تنطبق عليك أو على مستخدميك ، فلماذا تنفذها؟ ما الذي يمكن أن يفعله الشخص الأعمى باستخدام أداة لتحرير الصور؟
الحقيقة هي أنك محق في درجة معينة. إذا كنت قد أجريت بحثًا دقيقًا عن المستخدمين واستبعدت أي فرصة لمجموعة معينة من الأشخاص الذين يزورون موقعك على الويب ، فإن الأولوية لتقديم الطعام إلى مجموعة الأشخاص هذه تتضاءل قليلاً.
ومع ذلك ، فإن إجراء هذا البحث أمر أساسي في الدفاع عن مثل هذا البيان. هل تعلم أن هناك [لاعبين أعمى؟](http://audiogames.net) وحتى [المصورين المكفوفين؟](http://peteeckert.com/) . ربما كنت تعرف [أن الموسيقيين أصمّاء](http://mentalfloss.com/article/25750/roll-over-beethoven-6-modern-deaf-musicians) ؟
إذا فعلت ذلك ، خير لك. إذا لم يكن كذلك ، أعتقد أن هذا يدفع وجهة نظري أكثر إلى المنزل.
تصبح الصورة أكثر تعقيدًا عندما ننظر إلى تشريع يفرض عليك فعليًا إمكانية الوصول إلى بعض مواقع الويب وتطبيقات الويب. المثال الرئيسي هو [القسم 508](http://jimthatcher.com/webcourse1.htm) من الولايات المتحدة. في الوقت الحالي ، يشير هذا القانون بشكل أساسي إلى المنظمات الحكومية ومواقع القطاع العام ، إلخ. ومع ذلك ، فإن القوانين تتغير.
في العام الماضي ، أدرجت مواقع الخطوط الجوية في هذه القائمة ، مما يعني أنه حتى في أوروبا ، تطورت مواقع شركات الطيران على شبكة الإنترنت لتسهيل الوصول إلى المحتوى الخاص بها. عدم القيام بذلك يمكن أن يؤدي إلى حصول شركتك على غرامة تصل إلى عشرات الآلاف من الدولارات عن كل يوم لم يتم إصلاح المشكلة فيه.
هناك اختلافات في هذا التشريع في جميع أنحاء العالم ، بعضها أشد وشمولًا من غيرها. عدم معرفة هذه الحقيقة لا يجعل الدعوى تختفي للأسف.
## حسنًا ، إمكانية الوصول هي مشكلة كبيرة. الآن كيف ننفذه؟
هذا السؤال ، للأسف ، يصعب الإجابة عليه أكثر مما قد يبدو. اقتباس هاري بوتر في الأعلى هناك لسبب ، وليس لي قارئا فانتازيا متعطشا.
كما ذكرت أعلاه ، تعد إمكانية الوصول مهمة لمجموعة كبيرة من الأشخاص المختلفين ، لكل منهم احتياجاته الخاصة. إن جعل موقع الويب يعمل بشكل حرفي للجميع يمثل مهمة كبيرة ومستمرة.
لإضفاء القليل من طريقة على الجنون ، تم إنشاء إرشادات إمكانية الوصول إلى محتوى الويب أو [WCAG](https://www.wuhcag.com/web-content-accessibility-guidelines/) . يحتوي هذا المستند على عدد من المعايير التي يمكنك استخدامها للتحقق من موقع الويب الخاص بك. في الوقت الحالي ، سأغطي بعض أهم الأساسيات هنا. سأوجهك إلى الثمار المعلقة ، إذا جاز التعبير. في المقالات التالية ، سأناقش المزيد من التقنيات المتقدمة مثل \[WAI-ARIA\] وهو أمر مهم للتطبيقات التي تعتمد على JavaScript.
### تحدث مثل السكان الأصليين
مواصفات HTML عبارة عن مستند يصف كيفية استخدام اللغة لإنشاء مواقع ويب. إن التقنيات المساعدة ، مثل برامج قراءة الشاشة وبرامج التعرف على الكلام إلخ ، على دراية بهذا المستند. على الرغم من ذلك ، غالبًا ما لا يكون مطورو الويب ، أو على الأقل غير كافٍ ، ويعتقدون أن شيئًا كهذا على ما يرام:
```html
<div class="awesome-button"></div>
<span><strong>Huge heading I will style with CSS later</strong></span>
<span class="clickable-with-JavaScript">English</span>
```
خمين ما؟ كل ثلاثة من هذه العناصر كسر عدة معايير WCAG ، وبالتالي لا يمكن الوصول إليها على الإطلاق.
يكسر العنصر الأول ما يسمى "الاسم ، الدور ، القيمة ، المعيار" ، والذي ينص على أن جميع العناصر على صفحة الويب يجب أن تعرض اسمها ، ودورها (مثل الزر) وقيمتها (مثل محتويات حقل تحرير). للتقنيات المساعدة. لا يوفر هذا div أيًا من الثلاثة ، مما يجعله غير مرئي لقراء الشاشة.
يشبه العنصر الثاني شكلًا مرئيًا بعد تصميمه باستخدام CSS ، لكن معناه امتداد. لذلك ، لن تعرف التقنيات المساعدة عنوانها. سيقرأ قارئ الشاشة هذا كنص عادي ، بدلاً من العنوان. غالبًا ما يكون لدى قارئ الشاشة مفتاح تشغيل سريع للانتقال سريعًا إلى أقرب عنوان ، ولن يتم تضمين هذا العنوان في هذا النطاق.
يمكن أن يكون العنصر الثالث على سبيل المثال عنصرًا يمكن للمستخدم النقر عليه لتغيير لغة موقع الويب. ربما ستتوسع قائمة رسوم متحركة من اللغات عند النقر عليها. ومع ذلك ، فهذه أيضًا فترة ولا تعرض دورها (الرابط ، أو الزر) ، مما يجعل التقنيات المساعدة تعتقد أن هذه هي الكلمة الإنجليزية فقط مع بعض التصميم.
Spans و divs غير عناصر. أنها تهدف إلى احتواء عناصر أخرى ، وليس لتكون العناصر نفسها. يمكنك إصلاحها بطريقتين:
* يمكنك إضافة سمات ARIA-يدوياً إلى العناصر المذكورة أعلاه. هذا موضوع متقدم وخارج نطاق هذه المقالة.
* أو يمكنك ببساطة القيام بذلك:
```html
<button>This is a button</button>
<h2>Here's a heading level two</h2>
<a href="JavascriptThing">English</a>
```
فقاعة. فجأة ، كل هذه العناصر يمكن الوصول إليها بشكل كامل ، فقط باستخدام HTML الأصلي. HTML بالطريقة التي كان من المفترض أن يتم استخدامها ، وبعبارة أخرى.
### لا يمكن لأي مؤسسة الوقوف بدون هيكل
وقبل ذلك بقليل ، تطرقت إلى مفاتيح الاختصار الخاصة بقارئ الشاشة للقفز من العنوان إلى العنوان. هناك في الواقع العديد من مفاتيح الاختصار مثل هذه أن تقفز بسرعة إلى أقرب الجدول ، حقل النموذج ، والارتباط الخ. إن التأكد من أن هذه العناوين في الواقع في أماكن منطقية هو ممارسة جيدة ويقلل حقا من مستويات الإجهاد التي يعاني منها مستخدمو التكنولوجيا المساعدة ، وهو أمر جيد إذا كنت تريد استمرار الزوار في زيارة موقعك الإلكتروني.
تذكر أيضًا أن العناوين هرمية. إذا كنت تستخدم h2 ، فتأكد من أن h3's التي تتبعها بالفعل لها علاقة بهذا h2. لا تضع h3 للحصول على تفاصيل الاتصال أسفل h2 الخاص بك لمشاركات المدونة الأخيرة. تشبيه جيد هنا هو كتاب به فصول ، يحتوي على أقسام فرعية. أنت لن تضع قسماً على خبز البسكويت في منتصف فصل حول تحضير الخضار ... أو ... أنت لا… صحيح؟
### ما هو البديل؟
الصور الموجودة على موقع الويب رائعة. إنهم يضيفون طبقة جديدة إلى المحتوى الخاص بك ، يمكن أن يجعلوا تجربة زوار موقعك أكثر غامرة وبصفة عامة تبدو فقط جيدة بين كل هذا النص. يمكن أن تقول الصورة أكثر من ألف كلمة ، أليس كذلك؟
من المؤكد. هذا هو ، إذا كنت تستطيع رؤيتها. في مواصفات HTML5 ، يجب أن تحتوي سمة img- دائمًا على سمة alt. هذه السمة تعني كبديل للصورة في حالة عدم رؤيتها. سيكون هذا صحيحًا بالنسبة للزوار المكفوفين لموقعك الإلكتروني ، ولكن أيضًا عندما لا يمكن تحميل صورتك لسبب ما. لا يؤدي عدم إضافة علامة alt إلى سمة img إلى كسر إمكانية الوصول فقط ، بل يتعارض مع مواصفات HTML5.
إنني أتوسل إلى أي مطور ويب يدرك أنه يقوم بذلك لأكل قبعة المبرمج الخاصة به والعمل على Windows 95 بشكل خاص لمدة أسبوع. بعد انتهاء الوقت ، اكتب مقالاً عن ما تعلمته من هذه المحنة حتى أتمكن من الضحك أثناء تناول القهوة بعد الظهر.
الآن ، هناك واحد التحذير هنا. تُعد سمات Alt إلزامية وفقًا لمواصفات HTML5 ، ولكنها ليست إلزامية لملئها فعليًا. `<img src="awesome-image.jpg", alt="">` رمز HTML5 قانونيًا.
هل يجب عليك ملء علامات alt-alt لجميع الصور؟ ذلك يعتمد على الصورة ، حقا. بالنسبة إلى صور الخلفية ، لا تكون الإجابة عادةً ، ولكن يجب عليك استخدام CSS لتلك الرسائل على أي حال.
بالنسبة إلى الصور الزخرفية البحتة التي لا تحتوي على معلومات فيها على الإطلاق ، يمكنك مجانًا الاختيار مجانًا. إما وضعها في شيء مفيد وصفي أو لا شيء على الإطلاق.
بالنسبة للصور التي تحتوي على معلومات ، مثل كتيب ، وخريطة ، ومخطط ، وما إلى ذلك ، لا تقوم بإضافة نص بديل فواصل WCAG ما لم تقدم بديلًا نصيًا. عادة ما تكون هذه سمة alt ، ولكن يمكن أيضًا أن تكون كتلة نص أسفل أو بجوار الصورة.
بالنسبة لصور النص ، يمكن إما تضمين النص في سمة alt أو عرضه بطريقة بديلة. تكمن المشكلة في أن إضافة بديل نصي على نفس الصفحة سيؤدي في الأساس إلى عرض نفس المحتوى مرتين للأشخاص الذين يمكنهم رؤية الصورة ، وهذا هو السبب في أن سمة alt تكون أفضل في هذه الحالة.
يجب أن يوفر النص السياق والمعلومات التي تعتبر بديلاً لرؤية الصورة. لا يكفي ببساطة أن تكتب "صورة لبالونات الهواء الساخن" - لماذا توجد صور البالون هناك؟ إذا كانت الصورة منمنمة أو تحمل معنى عاطفيًا ، فيمكن تضمين ذلك.
### لا أستطيع قراءة الشخبطة يا بني
حتى الأشخاص الذين لا يرتدون نظارات ولا يعانون من مشكلة في البصر لديهم يستفيدون من سهولة قراءة الخط والتباين المناسب. أنا متأكد من أنك سوف تذلل إذا كان عليك أن تملأ شكلاً يتم فيه وضع الأحرف الصفراء الخفيفة ، التي لا تطاق ، على خلفية بيضاء. بالنسبة للأشخاص الذين ليس لديهم بصيرة جيدة ، مثل جدتك ، على سبيل المثال ، فإن هذا يصبح أسوأ بكثير.
يحتوي WCAG على نسب تباين للحروف الصغيرة والكبيرة ، وهناك الكثير من الأدوات لمعرفة ما إذا كانت نسب التباين قوية بما فيه الكفاية. المعلومات والأدوات موجودة ، استخدمها.
يعد استخدام مدقق تباين لون [WebAIM](https://webaim.org/resources/contrastchecker/) مكانًا جيدًا لبدء التحقق من تباين الألوان.
### ماذا يفعل هذا الزر؟
بينما نحن في موضوع النماذج ، دعونا نلقي نظرة سريعة على علامة `input` . هذا الرجل الصغير مهم جدا.
عندما تضع بعض حقول الإدخال على صفحة ويب ، يمكنك استخدام التصنيفات ... حسناً. ومع ذلك ، فإن وضعهم بجانب بعضهم البعض ليس كافياً. السمة التي تريدها هي السمة for-والتي تأخذ معرف حقل الإدخال التالي. بهذه الطريقة ، تعرف التقنيات المساعدة التسمية التي يتم إقرانها مع حقل النموذج.
أعتقد أن أفضل طريقة لتوضيح ذلك هي إعطاء مثال على ذلك:
```html
<label for='username'>
<input type='text' id='username'>
```
سيؤدي هذا على سبيل المثال إلى أن قارئ الشاشة يقول "اسم المستخدم ، حقل تحرير النص" ، بدلاً من مجرد "إعداد حقل تعديل النص" ويطلب من المستخدم البحث عن تصنيف. هذا أيضًا يساعد الأشخاص الذين يستخدمون برنامج التعرف على الكلام.
### هذا أمر طويل
لنأخذ استراحة صغيرة أريدك أن تذهب إلى صفحة ويب مصممة تصميماً جيداً. يمكن أن يكون أي صفحة. هيا ، سأنتظر
الى الخلف؟ حسنا عظيم. الآن ، انظر إلى الصفحة مرة أخرى ولكن قم بتعطيل كل CSS. هل ما زالت تبدو جيدة؟ هل لا يزال المحتوى الموجود على الصفحة بترتيب منطقي؟ إذا كان الأمر كذلك ، عظيم. لقد عثرت على صفحة بهيكل HTML لائق. (إحدى الطرق لعرض صفحة بدون CSS بسهولة هي تحميل الموقع في [أداة تقييم إمكانية الوصول إلى الويب WAVE](http://wave.webaim.org) لـ WebAIM ، ثم النقر فوق علامة التبويب "بدون أنماط" لمشاهدتها بدون الأنماط.)
إن لم يكن ، عظيم. الآن لديك انطباع عن ما يجب علي التعامل معه بشكل يومي عندما أواجه موقعًا منظمًا بشكل سيء.
الإفصاح الكامل: أميل إلى اللعنة عندما يحدث هذا. بصوت عالي. مع النشاط.
لماذا الامر مهم لهذه الدرجة؟ سأشرح.
_تنبيه المفسد!_ بالنسبة لأولئك الذين غطوا فقط المناهج HTML / CSS حتى الآن ، ونحن في طريقنا إلى القفز قليلا.
تعمل قارئات الشاشة والتقنيات المساعدة الأخرى على عرض تمثيل من أعلى إلى أسفل لصفحة ويب استنادًا إلى DOM لموقعك على الويب. يتم تجاهل كل CSS المغلق في هذا الإصدار من صفحة الويب.
يرمز DOM إلى نموذج كائن المستند وهو بنية تشبه الشجرة لعناصر HTML لموقعك على الويب. جميع عناصر HTML الخاصة بك هي عبارة عن نقاط مرتبطة ارتباطًا هرميًا استنادًا إلى علامات HTML التي تستخدمها وجافا سكريبت. يستخدم قارئات الشاشة شجرة DOM هذه للعمل باستخدام شفرة HTML الخاصة بك.
إذا وضعت العنصر في أعلى عنصرك ، فسيظهر في أعلى شجرة DOM أيضًا. لذلك ، فإن قارئ الشاشة يضعها في الأعلى أيضًا ، حتى إذا قمت بنقلها إلى أسفل الصفحة باستخدام CSS.
لذا ، فإن النصيحة الأخيرة التي أريد أن أقدمها لك هي أن تولي اهتماما لترتيب HTML الخاص بك ، وليس فقط موقع الويب الخاص بك النهائي مع CSS المضافة. هل لا يزال من المنطقي دون CSS؟ عظيم!
أوه ... لا؟ في هذه الحالة .. قد تسمع في يوم من الأيام لعنة مكتومة تنقلكم على نسيم بارد أثناء المشي في الخارج. سيكون ذلك على الأرجح أنا ، زيارة موقع الويب الخاص بك.
في هذه الحالة ، ليس لدي سوى كلمتين لك. غالباً ما سمعت نفس هاتين الكلمتين الموجهتين إليّ عندما كتبت بعض الكود الشريرة ومن دواعي سروري أن أخبرك: "اذهب إلى الإصلاح!"
### لون التباين
يجب أن يكون التباين بالألوان أقل من 4.5: 1 للنص العادي و 3: 1 للنص الكبير. يتم تعريف "نص كبير" على أنه نص لا يقل عن 18 نقطة (24 بكسل) أو 14 نقطة (18.66 بكسل) وبخط عريض. [مدقق التباين](https://webaim.org/resources/contrastchecker/)
## استنتاج
لقد أخبرتك عن إمكانية الوصول ، وما هي ، وما هو غير ذلك ، ولماذا هو مهم.
لقد أعطيتك أيضًا الأساسيات ، أساسيات الحصول على حق الوصول. ومع ذلك ، فهذه الأساسيات قوية جدًا ويمكن أن تجعل حياتك أسهل كثيرًا عند الترميز للوصول.
إذا تحدثنا في شروط لجنة الاتصالات الفيدرالية FCC ، يجب أن تضعها في اعتبارك أثناء تنفيذ منهج HTML / CSS وكذلك منهج جافا سكريبت JavaScript.
في مقالات لاحقة ، سوف أتطرق إلى عدد من المواضيع الإضافية. عدد من الأسئلة سأجيب عليها هي:
* يبدو أن إضافة عناوين منظمة تبدو فكرة جيدة ، ولكنها لا تتناسب مع تصميمي. ماذا أفعل؟
* هل هناك طريقة بالنسبة لي لكتابة المحتوى فقط قارئات الشاشة والتقنيات المساعدة الأخرى؟
* كيف يمكنني جعل مكونات JavaScript مخصصة قابلة للوصول؟
* ما الأدوات الموجودة ، بالإضافة إلى اختبار المستخدم الشامل ، التي يمكن استخدامها لتطوير التجربة الأكثر قوة وسهولة الوصول إلى أكبر مجموعة من المستخدمين؟

71
guide/arabic/accessibility/accessibility-examples/index.md
View File

@ -1,71 +0,0 @@
---
title: Accessibility Examples
localeTitle: أمثلة على سهولة الوصول
---
<span dir=rtl>
## أمثلة على سهولة الاستخدام في التطبيق العملي
أكتب هذا الدليل المختصر لتقديم أمثلة عملية عن كيفية تنفيذ إمكانية الوصول في مواقع الويب. لم يتم التأكيد على إمكانية الوصول أثناء المدرسة ولا يتم التركيز عليها بشكل كاف في العالم الحقيقي لتطوير الويب. آمل أن تشجّع هذه المقالة ، إلى جانب العديد غيرها ، المطوّرين على إنشاء مواقع يسهل الوصول إليها من الآن فصاعدًا. لقد ساعدني دائمًا في الحصول على أمثلة عملية حول كيفية القيام بالأشياء. لذلك سيركز هذا الدليل على أمثلة العالم الحقيقي التي واجهتها في حياتي اليومية كمطور ويب.
### تخطي الملاحة
من أجل منح المستخدمين غير النظر تجربة ممتعة على موقع الويب الخاص بك ، يجب أن يكونوا قادرين على الوصول إلى المحتوى بسرعة وكفاءة. إذا لم تجرب استخدام موقعًا على الويب من خلال قراءة الشاشة ، فأوصيك بذلك. إنها أفضل طريقة لاختبار مدى سهولة التنقل في الموقع للمستخدمين غير النظر. NVDA هو تطبيق جيد لقراءة الشاشة يتم توفيره مجانًا. ولكن إذا كنت تستخدم قارئ الشاشة وتجد أنه من المفيد التفكير في تقديم تبرع لفريق التطوير. يمكن تنزيل قارئ الشاشة من [nvaccess.org](https://www.nvaccess.org/download/) .
للسماح للمستخدمين غير النظر بالانتقال إلى المحتوى الرئيسي للموقع وتجنب الجدولة عبر جميع روابط التنقل الرئيسية:
1. إنشاء "تخطي صلة الملاحة" التي تعيش مباشرة تحت افتتاح `body` علامة.
```html
<a tabindex="0" class="skip-link" href="#main-content">Skip to Main Content</a>
```
`tabindex="0"` يضاف للتأكد من أن الوصلة هي لوحة المفاتيح قابلة للتركيز على جميع المتصفحات. يمكن العثور على مزيد من المعلومات حول إمكانية الوصول إلى لوحة المفاتيح على [webaim.org](https://webaim.org/techniques/keyboard/tabindex) .
2. يجب أن يرتبط ارتباط "تخطي التنقل" بعلامة html الرئيسية في مستند صفحة الويب الخاص بك باستخدام علامة التعريف.
```
<main id="main-content">
...page content
</main>
```
3. إخفاء رابط "تخطي التنقل" افتراضيًا. يضمن هذا أن يكون الرابط مرئيًا فقط للمستخدمين الذين يتم رؤيتهم عند التركيز على الرابط.
* قم بإنشاء فصل للرابط الذي يمكن تنسيقه باستخدام CSS. في المثال الخاص بي قد أضفت `skip-link` .
<span dir=ltr>
```
.skip-link {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
-webkit-clip-path: inset(50%);
clip-path: inset(50%);
border: 0;
}
.skip-link:active, .skip-link:focus {
position: static;
width: auto;
height: auto;
overflow: visible;
clip: auto;
white-space: normal;
-webkit-clip-path: none;
clip-path: none;
}
```
</span>
تخفي أنماط CSS هذه الارتباط افتراضيًا وتعرض الارتباط فقط عند تلقي التركيز على لوحة المفاتيح. لمزيد من المعلومات ، يرجى زيارة [a11yproject](http://a11yproject.com/posts/how-to-hide-content) وهذا [بلوق وظيفة](http://hugogiraudel.com/2016/10/13/css-hide-and-seek/) .
### الجداول سهلة الوصول
### علامات التبويب يمكن الوصول إليها
</span>

42
guide/arabic/accessibility/accessibility-tools-for-web-developers/index.md
View File

@ -1,42 +0,0 @@
---
title: Accessibility Tools for Web Developers
localeTitle: أدوات الوصول لمطوري الويب
---
## أدوات الوصول لمطوري الويب
هناك العديد من الأدوات والموارد عبر الإنترنت التي يمكنها مساعدتك على ضمان تلبية تطبيق الويب الخاص بك لكافة متطلبات إمكانية الوصول.
1. **[أدوات مطور إمكانية الوصول](https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en)**
هذه هي إضافة Google Chrome التي ستضيف جزءًا جانبيًا جديدًا من "إمكانية الوصول" في علامة التبويب "عناصر" إلى أدوات مطوري برامج Chrome. يعرض هذا الجزء الجديد أية خصائص ذات صلة بجانب إمكانية الوصول للعنصر الذي تقوم بفحصه حاليًا. يضيف هذا الامتداد أيضًا تدقيق إمكانية الوصول الذي يمكن استخدامه للتحقق مما إذا كانت صفحة الويب الحالية تنتهك أي قواعد لإمكانية الوصول.
2. **[فأس](https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)**
يمكن لإضافات Google Chrome العثور على عيوب إمكانية الوصول في صفحتك على الويب.
3. **[مولد لوحة الألوان الآمنة](http://colorsafe.co)**
يمكن أن يساعدك موقع الويب هذا في إنشاء لوحة ألوان تعتمد على إرشادات WCAG لنسب التباين في النص والورقة.
4. **[تحقق من بلدي الألوان](http://www.checkmycolours.com)**
موقع ويب للتحقق مما إذا كان موقعك الحالي يلبي متطلبات إمكانية الوصول للون والتباين.
5. **[لون أوراكل](http://colororacle.org)**
تطبيق يحاكي عمى الألوان. وهي متوفرة على أنظمة Windows و Mac و Linux.
6. **[tota11y](http://khan.github.io/tota11y/)**
مجموعة أدوات عرض إمكانية الوصول التي تتحقق من أداء موقعك على الويب باستخدام التقنيات المساعدة.
7. **[AccessLint](https://www.accesslint.com)**
تطبيق GitHub الذي يتحقق من طلبات السحب لمسائل إمكانية الوصول.
* * *
#### المزيد من المصادر
يمكنك العثور على العديد من الأدوات لتصميم صفحات الويب في [هذه القائمة](http://www.d.umn.edu/itss/training/online/webdesign/tools.html) التي تقدمها جامعة مينيسوتا دولوث.

11
guide/arabic/accessibility/automated-testing/index.md
View File

@ -1,11 +0,0 @@
---
title: Automated Accessibility Testing Tools
localeTitle: أدوات اختبار إمكانية الوصول التلقائي
---
## اختبار الوصول التلقائي
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/accessibility/automated-testing/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

27
guide/arabic/accessibility/index.md
View File

@ -1,27 +0,0 @@
---
title: Accessibility
localeTitle: إمكانية الوصول
---
## إمكانية الوصول
**تعني إمكانية الوصول إلى الويب أن الأشخاص ذوي الإعاقة يمكنهم استخدام الويب** .
وبشكل أكثر تحديدًا ، تعني إمكانية الوصول إلى الويب أن الأشخاص ذوي الإعاقة يمكنهم إدراك الويب وفهمه والتنقل فيه والتفاعل معه ، وأن بإمكانهم المساهمة في الويب. كما تفيد إمكانية الوصول إلى الإنترنت الآخرين ، بما في ذلك [كبار السن](https://www.w3.org/WAI/bcase/soc.html#of) ذوي القدرات المتغيرة بسبب الشيخوخة.
تشمل إمكانية الوصول إلى الويب جميع الإعاقات التي تؤثر على الوصول إلى الويب ، بما في ذلك البصرية والسمعية والجسدية والكلامية والمعرفية والعصبية الإعاقة. يوضح المستند " [كيف يعامل الأشخاص ذوي الإعاقة على الويب"](http://www.w3.org/WAI/intro/people-use-web/Overview.html) مدى اختلافه تؤثر الإعاقات على استخدام الويب وتتضمن سيناريوهات للأشخاص ذوي الإعاقات باستخدام الويب.
كما أن إمكانية الوصول إلى الويب **تفيد** الأشخاص _غير_ المعوقين. على سبيل المثال ، يتمثل أحد المبادئ الأساسية لإمكانية الوصول إلى الويب في تصميم مواقع الويب والبرامج مرنة للوفاء باحتياجات وتفضيلات وحالات المستخدم المختلفة. هذه **المرونة** أيضا تفيد الأشخاص _غير_ المعوقين في بعض الحالات ، مثل الأشخاص الذين يستخدمون اتصالاً بطيئًا بالإنترنت ، والأشخاص الذين لديهم "إعاقات مؤقتة" مثل ذراع مكسورة ، والأشخاص ذوي القدرات المتغيرة بسبب الشيخوخة. يصف المستند " [تطوير حالة عمل إمكانية الوصول إلى ويب للمؤسسة الخاصة بك"](https://www.w3.org/WAI/bcase/Overview) العديد فوائد مختلفة من الوصول إلى شبكة الإنترنت ، بما في ذلك **فوائد للمنظمات** .
يجب أن تشمل إمكانية الوصول إلى الويب أيضًا الأشخاص الذين ليس لديهم إمكانية الوصول إلى الإنترنت أو أجهزة الكمبيوتر.
تم تقديم دليل بارز لتطوير الويب بواسطة [اتحاد شبكة الويب العالمية (W3C)](https://www.w3.org/) ، وهي [مبادرة الوصول إلى الويب](https://www.w3.org/WAI/) من خلالها نحصل على [WAI-ARIA](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics) ، مجموعة تطبيقات الإنترنت الغنية سهلة الوصول. حيث تتعامل WAI مع دلالات لغة تأشير النص الفائق (HTML) لتسهيل إنشاء شجرة DOM ، تحاول ARIA إنشاء تطبيقات الويب ، خاصة تلك التي تم تطويرها باستخدام javascript و أجاكس ، أكثر سهولة.
يمكن أن يؤدي استخدام الصور والرسومات على مواقع الويب إلى تقليل إمكانية الوصول لأولئك الذين يعانون من إعاقات بصرية. ومع ذلك ، هذا لا يعني أن المصممين يجب تجنبه باستخدام هذه العناصر البصرية. عند استخدامها بشكل صحيح ، يمكن للعناصر المرئية أن تنقل الشكل والمظهر المناسبين للمستخدمين دون إعاقات ويجب استخدامها لنفعل ذلك. لاستخدام هذه العناصر بشكل مناسب ، يجب على مصممي الويب استخدام نص بديل لتوصيل رسالة هذه العناصر لأولئك الذين لا يستطيعون رؤيتها معهم. يجب أن يكون النص البديل قصيرًا ومختصرًا - [لا يزيد عن 5 إلى 15 كلمة بشكل عام](https://www.thoughtco.com/writing-great-alt-text-3466185) . اذا كان يستخدم الرسم لنقل المعلومات التي تتجاوز حدود النص البديل ، ويجب أن تكون هذه المعلومات موجودة أيضًا كنص على الويب حتى تتم قراءتها على شاشة القراء. [تعرف على المزيد حول النص البديل](https://webaim.org/techniques/alttext/) .
تمامًا مثل النص البديل للأشخاص الذين يعانون من ضعف البصر ، فإن نصوص الصوت مخصصة للأشخاص الذين لا يمكنهم الاستماع، حيث تقدم وثيقة مكتوبة أو نسخة مما يتم التحدث به للأشخاص الذين يعانون من صعوبة في السمع.
حقوق النشر © 2005 [اتحاد شبكة الويب العالمية](http://www.w3.org) ( [MIT](http://www.csail.mit.edu/) ، [ERCIM](http://www.ercim.org) ، [Keio](http://www.keio.ac.jp) ، [Beihang](http://ev.buaa.edu.cn) ). http://www.w3.org/Consortium/Legal/2015/doc-license
### معلومات أكثر:
[مقدمة w3.org لإمكانية الوصول.](https://www.w3.org/WAI/intro/accessibility.php) [مشروع A11Y](http://a11yproject.com/)

21
guide/arabic/agile/acceptance-criteria/index.md
View File

@ -1,21 +0,0 @@
---
title: Acceptance Criteria
localeTitle: معايير القبول
---
## معايير القبول
تعتبر "قصة المستخدم" ، كعنصر في backlog الخاص بك ، عنصرًا نائبًا للمحادثة. في هذه المحادثة ، يتوصل مالك المنتج وفريق التوصيل إلى فهم حول النتيجة المرجوة.
يخبر "معايير القبول" فريق التسليم كيف يجب أن تتصرف التعليمة البرمجية. تجنب كتابة **"كيف"** قصة المستخدم ؛ الحفاظ على **"ما"** . إذا كان الفريق يتبع التطوير الموجه للاختبار (TDD) ، فقد يوفر إطارًا للاختبارات التلقائية. ستكون معايير القبول هي بداية خطة الاختبار لفريق ضمان الجودة.
والأهم من ذلك ، إذا كانت القصة لا تلبي كل معايير القبول ، فيجب ألا يقبل مالك المنتج القصة في نهاية التكرار.
يمكن النظر إلى معايير القبول كأداة لحماية فريق التسليم. عندما يلتزم فريق التسليم بمجموعة ثابتة من الأخبار في تخطيط Sprint ، يلتزمون بمجموعة ثابتة من معايير القبول أيضًا. هذا يساعد على تجنب زحف النطاق.
خذ بعين الاعتبار الوضع التالي: عند قبول قصة المستخدم ، يقترح مالك المنتج إضافة شيء لم يكن في نطاق قصة المستخدم. في هذه الحالة ، يكون فريق التسليم في وضع يسمح له برفض هذا الطلب (مهما كان صغيراً) وطلب من مالك المنتج إنشاء قصة مستخدم جديدة يمكن العناية بها في سباق آخر.
#### معلومات اكثر:
يوفر Nomad8 [أسئلة وأجوبة حول معايير القبول](https://nomad8.com/acceptance_criteria/)
يقود رشيق على [معايير القبول](https://www.leadingagile.com/2014/09/acceptance-criteria/)

133
guide/arabic/agile/acceptance-testing/index.md
View File

@ -1,133 +0,0 @@
---
title: Acceptance Testing
localeTitle: اختبار القبول
---
## اختبار القبول
اختبار القبول ، وهو أسلوب اختبار يتم تنفيذه لتحديد ما إذا كان نظام البرنامج قد استوفى مواصفات المتطلبات أم لا. يتمثل الغرض الرئيسي من هذا الاختبار في تقييم امتثال النظام لمتطلبات العمل والتحقق مما إذا كان قد استوفى المعايير المطلوبة للتسليم إلى المستخدمين النهائيين.
هناك عدة أشكال لاختبار القبول:
\-> خ١تبار قبول المستخدم
\-> ختبار قبول الأعمال٢
\-> ا٣ختبار ألفا
\-> ا٤ختبار بيتا
# معايير القبول
يتم تعريف معايير القبول على أساس السمات التالية
\-> الدقة الوظيفية والاكتمال
\-> سلامة البيانات
\-> تحويل البيانات
\-> سهولة الاستخدام
\-> الأداء
\-> في الوقت المناسب
\-> السرية والتوافر
\-> قابلية التثبيت والترقية
\-> التدرجية
\-> وثائق
# خطة اختبار القبول - السمات
يتم تنفيذ أنشطة اختبار القبول على مراحل. أولاً ، يتم تنفيذ الاختبارات الأساسية ، وإذا كانت نتائج الاختبار مرضية ، يتم تنفيذ سيناريوهات أكثر تعقيدًا.
تشتمل خطة اختبار القبول على السمات التالية:
\-> مقدمة
\-> فئة اختبار القبول
\-> بيئة التشغيل
\-> معرف حالة الاختبار
\-> عنوان الاختبار
\-> اختبار الهدف
\-> إجراءات الاختبار
\-> جدول الاختبار
\-> الموارد
\=> تم تصميم أنشطة اختبار القبول للوصول إلى أحد الاستنتاجات:
قبول النظام كما سلمت
اقبل النظام بعد إجراء التعديلات المطلوبة
لا تقبل النظام
# تقرير اختبار القبول - السمات
يحتوي تقرير اختبار القبول على السمات التالية:
\-> تقرير المعرف
\-> ملخص النتائج
\-> الاختلافات
\-> توصيات
\-> ملخص قائمة المهام
# \-> قرار الموافقة
يركز اختبار القبول على التحقق مما إذا كان البرنامج المطور يلبي جميع المتطلبات. هدفها الرئيسي هو التحقق مما إذا كان الحل الذي تم تطويره يلبي توقعات المستخدمين.
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
اختبار القبول هو ممارسة راسخة في تطوير البرمجيات. اختبار القبول هو جزء رئيسي من اختبار وظيفي من التعليمات البرمجية الخاصة بك.
يختبر اختبار القبول أن الكود ينفذ كما هو متوقع ، أي ينتج الناتج المتوقع ، بالنظر إلى المدخلات المتوقعة.
يتم استخدام اختبار القبول لاختبار كتل وظيفية أكبر نسبيًا من البرامج الملقبة بميزات.
### مثال
لقد قمت بإنشاء صفحة تتطلب أن يقوم المستخدم أولاً بإدخال اسمه في مربع حوار قبل أن يتمكن من مشاهدة المحتوى. لديك قائمة بالمستخدمين المدعوين ، لذلك سيتم إرجاع أي مستخدمين آخرين لخطأ.
هناك عدة سيناريوهات هنا مثل:
* في كل مرة تقوم فيها بتحميل الصفحة ، تحتاج إلى إدخال اسمك.
* إذا كان اسمك في القائمة ، سيختفي مربع الحوار وستظهر لك المقالة.
* إذا لم يكن اسمك في القائمة ، فسوف يظهر مربع الحوار خطأ.
يمكنك كتابة اختبارات القبول لكل من هذه الميزات الفرعية لميزة مربع الحوار الأكبر
وبصرف النظر عن الرمز الذي يعالج البنية الأساسية لكيفية تنفيذ الاختبار ، قد يبدو اختبارك للسيناريو الأول (في pseudocode):
بالنظر إلى أن الصفحة مفتوحة يجب أن يكون مربع الحوار مرئيًا ويجب أن يحتوي مربع الحوار على مربع إدخال ويجب أن يحتوي مربع الإدخال على نص موضع مؤقت "اسمك ، من فضلك!"
### ملاحظات
القبول يمكن كتابة الاختبارات بأي لغة وتشغيلها باستخدام الأدوات المختلفة المتاحة التي من شأنها أن تعتني بالبنية الأساسية المذكورة أعلاه ، مثل فتح متصفح ، وتحميل صفحة ، وتوفير menthods للوصول إلى عناصر على الصفحة ، ومكتبات التأكيد ، وما إلى ذلك.
في كل مرة تقوم فيها بكتابة جزء من البرنامج سيتم استخدامه مرة أخرى (حتى لو كان ذلك بنفسك) ، فإنه يساعدك على كتابة اختبار له. عندما تقوم بنفسك أو بأخرى بإجراء تغييرات على هذا الرمز ، فإن تشغيل الاختبارات سيضمن عدم قيامك بكسر الوظائف الموجودة.
وعادة ما يتم تنفيذها من قبل المستخدمين أو خبراء الموضوع. يطلق عليه أيضا باسم اختبار قبول المستخدم (UAT). UAT ينطوي على معظم سيناريوهات الحياة الحقيقية المشتركة. بخلاف اختبار النظام ، فإنه لا يركز على الأخطاء أو الأعطال ، ولكن على الوظيفة. يتم إجراء UAT في نهاية دورة حياة الاختبار وسيقرر ما إذا تم نقل البرنامج إلى البيئة التالية أم لا.
من الطرق الجيدة لتحديد اختبارات القبول التي يجب كتابتها إضافة معايير القبول إلى قصة مستخدم. باستخدام معايير القبول ، يمكنك تحديد متى تكون قصة المستخدم جاهزة للنشر وإتمام المشكلة لرغباتك.
في مشروع Agile من المهم أن يكون لدى الفريق معايير قبول محددة لكافة قصص المستخدمين. سوف يستخدم اختبار القبول المعايير المحددة لتقييم الأداء الوظيفي. عندما تتمكن القصة من اجتياز جميع معايير القبول ، تكون قد اكتملت.
يمكن اختبار القبول أيضا التحقق من صحة ما إذا كانت ملحمة / قصة / مهمة كاملة تستوفي معايير القبول المحددة. وعلى النقيض من تعريف "الفعل" ، يمكن أن تغطي هذه المعايير حالات الأعمال المحددة التي يريد الفريق حلها. وهذا يوفر قياسًا جيدًا لجودة العمل.
#### معلومات اكثر:
* [مجلس المؤهلات الدولي لاختبار البرمجيات](http://www.istqb.org/)

53
guide/arabic/agile/actual-time-estimation/index.md
View File

@ -1,53 +0,0 @@
---
title: Actual Time Estimation
localeTitle: تقدير الوقت الفعلي
---
## تقدير الوقت الفعلي
التقدير الفعلي للوقت هو عملية التنبؤ بأكثر مقدار من الجهد واقعية (يُعبَّر عنه من حيث عدد ساعات العمل أو النقود) المطلوب لتطوير أو صيانة برنامج يعتمد على مدخلات غير كاملة وغير مؤكدة وصاخبة. يمكن استخدام تقديرات الجهد كمدخلات في خطط المشروع ، خطط التكرار ، الميزانيات ، تحليلات الاستثمار ، عمليات التسعير وجولات العطاءات.
### للدولة من الناحية العملية
تشير الدراسات الاستقصائية المنشورة حول ممارسة التقدير إلى أن تقدير الخبراء هو الاستراتيجية السائدة عند تقدير جهد تطوير البرامج.
وعادة ما تكون تقديرات الجهد مفرطة في التفاؤل وهناك ثقة مفرطة في دقتها. ويبدو أن متوسط ​​مجهود الجهد يقارب 30٪ ولا يتناقص مع مرور الوقت. لمراجعة استطلاعات خطأ تقدير الجهد ، راجع. ومع ذلك ، فإن قياس خطأ التقدير يمثل مشكلة ، انظر تقييم دقة التقديرات. يتضح مدى الثقة المفرطة في دقة تقديرات الجهد من خلال النتيجة التي توصلت إليها ، في المتوسط ​​، إذا كان أحد متخصصي البرامج واثقين بنسبة 90٪ أو "شبه متأكدين" من تضمين الجهد الفعلي في الحد الأدنى من الحد الأقصى ، فإن التردد الملحوظ بما في ذلك الجهد الفعلي هو 60-70 ٪ فقط.
يُستخدم مصطلح "تقدير الجهد" حاليًا للدلالة على أنه مفاهيم مختلفة مثل الاستخدام الأكثر احتمالًا للجهد (القيمة النموذجية) ، والجهد الذي يقابل احتمال 50٪ من عدم تجاوز (الوسيط) ، والجهد المخطط له ، والجهد المدرج في الميزانية أو الجهد المستخدم لاقتراح عطاء أو سعر للعميل. يعتقد أن هذا أمر مؤسف ، لأن مشاكل الاتصال قد تحدث ولأن المفاهيم تخدم أهدافًا مختلفة.
### التاريخ
لقد عالج باحثو البرمجيات والممارسون مشاكل تقدير الجهد لمشروعات تطوير البرمجيات منذ الستينات على الأقل ؛ انظر ، على سبيل المثال ، العمل من قبل فار ونيلسون.
وقد ركزت معظم الأبحاث على بناء نماذج تقدير رسمية لجهد البرمجيات. كانت النماذج المبكرة تعتمد عادة على تحليل الانحدار أو مشتقة رياضيا من النظريات من المجالات الأخرى. ومنذ ذلك الحين ، تم تقييم عدد كبير من أساليب بناء النماذج ، مثل المناهج المستندة إلى التعليل القائم على أساس الحالة ، وأشجار التصنيف والتراجع ، والمحاكاة ، والشبكات العصبية ، وإحصاءات بايز ، والتحليل المعجمى لمواصفات المتطلبات ، والبرمجة الجينية ، والبرمجة الخطية ، والإنتاج الاقتصادي. النماذج ، والحوسبة الناعمة ، ونمذجة المنطق الضبابي ، والإحلال الإحصائي ، والتوليفات من اثنين أو أكثر من هذه النماذج.
ربما تكون أساليب التقدير الأكثر شيوعًا اليوم هي نماذج التقدير البارامترات COCOMO و SEER-SEM و SLIM. ولها أساسها في بحوث التقييم التي أجريت في السبعينيات والثمانينيات ، وتم تحديثها منذ ذلك الحين ببيانات معايرة جديدة ، وكان الإصدار الرئيسي الأخير هو COCOMO II في عام 2000. وتقترب طرق التقييم من المقاييس القائمة على الوظائف ، مثل الوظيفة. وتستند النقاط أيضًا إلى الأبحاث التي أجريت في السبعينيات والثمانينيات ، ولكن تمت معايرتها بمقاييس حجم معدلة ومناهج حساب مختلفة ، مثل نقاط حالة الاستخدام أو نقاط الكائن في التسعينيات و COSMIC في العقد الأول من القرن الحادي والعشرين.
يعتبر التقدير الفعلي للوقت طريقة تستند إلى الوقت لتقدير أعمال التطوير.
من الأهمية بمكان أن تكون قادراً على تقدير الوقت اللازم لإنجاز مشروع Agile ، لسوء الحظ ، إنه أيضاً أحد أكثر الأجزاء صعوبة في التخطيط لمشروع Agile.
وهدفها هو أفضل تقدير تقريبي لمقدار الوقت اللازم لإكمال مهمة تطوير معينة.
إحدى التقنيات التي يمكنك استخدامها هي تقدير الوقت الذي سيستغرقه إكمال قصص المستخدمين. عندما تفعل هذا ، تذكر أن تتشاور مع أعضاء آخرين من فريق رشيق الخاص بك. لكل قصة مستخدم ، تأكد من أنك تقدر الوقت الذي يكون واقعيًا وعمليًا ، ولكن ليس بقدر ما يتم تقاضي العميل مقابل عمل بسيط. استشر أعضاء فريقك حتى تتمكن من الاستفادة من خبراتهم حتى يتمكنوا من فهم مقدار العمل المطلوب والمدة التي سيستغرقها ذلك. عندما يكون لديك إجماع لكل قصة مستخدم ، يمكنك إضافة الأوقات للحصول على تقدير للوقت.
مع تغير متطلبات المشروع بمرور الوقت ، يمكنك تحديث التقدير. إذا فقد مشروع ما بعض الموارد المخصصة له في الأصل ، فقد تحتاج إلى قص قصص المستخدمين لتتمكن من إكمالها بنفس المقدار من الوقت الإجمالي. وبالمثل ، إذا كنت ترغب في تحسين جودة التطبيق ، فقد تحتاج إلى تخصيص مزيد من الوقت لكل قصة مستخدم للتأكد من أن فريقك لديه وقت لإنهاء التطبيق بالجودة المطلوبة.
بشكل عام ، يتم حساب هذه التقديرات باستخدام ساعات هندسية مثالية.
أمثلة:
**هذه المهمة ستكون كاملة في 10 أيام.**
أو…
**ستكتمل هذه المهمة في 10 يناير.**
أو…
**ستتطلب هذه المهمة 25 ساعة تطوير لإتمامها.**
### معلومات اكثر:
* [قيود رشيقة](http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/)
* [كيف يمكنك تقدير مشروع Agile؟](http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf)

11
guide/arabic/agile/alignment/index.md
View File

@ -1,11 +0,0 @@
---
title: Alignment
localeTitle: انتقام
---
## انتقام
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/alignment/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

25
guide/arabic/agile/application-lifecycle-management/index.md
View File

@ -1,25 +0,0 @@
---
title: Application Lifecycle Management
localeTitle: إدارة دورة حياة التطبيق
---
## إدارة دورة حياة التطبيق
تعد إدارة دورة حياة التطبيقات (ALM) ، المرتبطة بشكل شائع مع دورة حياة تطوير البرامج (SDLC) ، منظورًا أوسع يتناسب بشكل أفضل مع مفهوم دورة حياة المنتج. يعتبر التطوير (SDLC) جزءًا فقط من دورة حياة التطبيق ومن ثم يتم تمثيله كجزء من ALM.
يمكن تقسيم ALM إلى ثلاثة مجالات متميزة: الحوكمة والتنمية والعمليات:
الحوكمة: يشمل كل من صنع القرار وإدارة المشروع لهذا التطبيق ، يمتد على كامل الوجود للتطبيق.
التطوير: عملية (SDLC) لإنشاء التطبيق فعليًا. بالنسبة لمعظم التطبيقات ، تظهر عملية التطوير مرة أخرى عدة مرات في عمر التطبيق ، بما في ذلك إصلاح الأخطاء والتحسينات والإصدارات الجديدة.
العمليات: العمل المطلوب لتشغيل وإدارة التطبيق ، وعادة ما يبدأ قبل فترة وجيزة من النشر ، ثم يعمل بشكل مستمر حتى تقاعد التطبيق. تتداخل في بعض الأحيان مع التنمية.
يمكن استخدام الأدوات لإدارة ALM ؛ تتضمن بعض الخيارات الأكثر شيوعًا ما يلي:
* اتلسيان [الجيرة](http://atlassian.com/software/jira)
* CA تكنولوجى [رالي](http://ca.com/us.html)
* [يعتقد أعمال](http://thoughtworks.com/products)
#### معلومات اكثر:
InfoQ - غارتنر والمشورة البرمجيات تفحص [أدوات إدارة دورة حياة رشيقة](http://www.infoq.com/news/2015/02/agile-management-tools/)

5
guide/arabic/agile/architectural-runway/index.md
View File

@ -1,5 +0,0 @@
---
title: Architectural Runway
localeTitle: المدرج المعماري
---
يحدد المدرج المعماري كل ما يحتاجه البرنامج قبل بدء المشروع. هذا يسمح للمطورين بضرب الأرض.

20
guide/arabic/agile/backlog-emergence-and-grooming/index.md
View File

@ -1,20 +0,0 @@
---
title: Backlog Emergence and Refinement
localeTitle: تراكم ظهور وتنعيم
---
## تراكم ظهور وتنعيم
تعد عملية تحسين تراكم المنتجات عملية مستمرة يجب أن تكون متزامنة مع عملية اكتشاف المنتج. بشكل عام ، سيعمل فريق Scrum بشكل تعاوني على تحسين عناصر تراكم المنتجات للسباقات الثنائية أو الثلاثة المقبلة.
يحدد مالك المنتج (الشخص المسؤول عن توضيح هدف السباق) نطاق سباقات السرعة القادمة من خلال تحديد أغلى قصص المستخدمين قيمة في تراكم المنتجات. يعتبر مالك المنتج أكثر من مجرد مدير مشروع تم إنشاؤه لتراكم المنتجات ، ويؤدي أدوارًا أكثر من مجرد قصص المستخدمين بالنيابة عن أصحاب المصلحة.
من دليل سكروم: تعد عملية تنقيح المنتج المتأخر بمثابة إضافة التفاصيل والتقديرات وترتيب العناصر في تراكم المنتج. هذه عملية مستمرة يتعاون فيها مالك المنتج وفريق التطوير على تفاصيل عناصر تراكم المنتجات. أثناء تنقيح تراكم المنتج ، تتم مراجعة العناصر وتنقيحها.
يقرر فريق سكروم كيف ومتى يتم التصفية. لا يستلزم الصقل عادة أكثر من 10٪ من قدرة فريق التطوير. ومع ذلك ، يمكن تحديث عناصر تراكم المنتجات في أي وقت بواسطة مالك المنتج أو حسب تقدير مالك المنتج. الهدف من التحسين هو الحصول على ما يكفي من عناصر تراكم المنتج "جاهز" لتخطيط Sprint القادم Sprint. بشكل عام ، سيقوم فريق scrum بشكل تعاوني بتحسين عناصر تراكم المنتجات الخاصة بالسباعتين التاليتين إلى السباقات الثلاثة التالية.
يعد ظهور الأعمال المتراكمة وصقلها مهام أساسية لكل فريق من أعضاء فريق سكروم. يحدد مالك المنتج نطاق سباقات السرعة المرتقبة من خلال تحديد أغلى قصص المستخدمين قيمة في تراكم المنتجات. على الرغم من أن مالك المنتج هو المسؤول عن الحفاظ على تراكم المنتج عند تسليم قيمة الذروة ، إلا أنه يحتاج إلى مساعدة فريق سكروم بأكمله للقيام بذلك. تغيير Sprint Backlog جزء من Sprint المستمر ولا يعتبر Refinement.
#### معلومات اكثر:
* [تحسين تنقيح تراكم المنتج](https://www.scrum.org/resources/blog/optimizing-product-backlog-refinement)
* دليل سكروم (http://www.scrumguides.org/)

11
guide/arabic/agile/backlog-item-effort/index.md
View File

@ -1,11 +0,0 @@
---
title: Backlog Item Effort
localeTitle: جهد البند تراكم
---
## جهد البند تراكم
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/backlog-item-effort/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

61
guide/arabic/agile/behavior-driven-development/index.md
View File

@ -1,61 +0,0 @@
---
title: Behavior Driven Development
localeTitle: تنمية السلوك مدفوعة
---
## تنمية السلوك مدفوعة
التنمية المدفوعة بالسلوك (BDD) هي عملية تطوير برمجيات انبثقت من ![التطوير المدفوع بالاختبار (TDD)](../test-driven-development/index.md) . يدمج التطوير المبني على السلوك بين التقنيات والمبادئ العامة للـ TDD مع أفكار من التصميم القائم على المجال والتحليل والتصميم الموجه للكائنات لتقديم فرق تطوير وإدارة البرامج بأدوات مشتركة وعملية مشتركة للتعاون في تطوير البرمجيات. إنها منهجية تطوير برمجيات يتم فيها تحديد وتخصيص تطبيق من خلال وصف كيفية ظهور سلوكه لمراقب خارجي.
على الرغم من أن BDD هو في الأساس فكرة عن كيفية إدارة تطوير البرمجيات من جانب المصالح التجارية والرؤية الفنية ، فإن ممارسة BDD تفترض استخدام أدوات برمجية متخصصة لدعم عملية التطوير.
على الرغم من أن هذه الأدوات غالباً ما يتم تطويرها خصيصًا للاستخدام في مشاريع BDD ، يمكن اعتبارها أشكالًا متخصصة من الأدوات التي تدعم التطوير القائم على الاختبار. الأدوات تعمل لإضافة الأتمتة إلى اللغة في كل مكان وهذا هو الموضوع الرئيسي لل BDD.
يركز BDD على:
* من أين تبدأ في هذه العملية
* ما لاختبار وما لا اختبار
* كم لاختبار في دفعة واحدة
* ما استدعاء الاختبارات
* كيف نفهم لماذا يفشل الاختبار
في قلب BDD هو إعادة التفكير في النهج لاختبار وحدة واختبار القبول التي تنشأ بطبيعة الحال مع هذه القضايا. على سبيل المثال ، يقترح BDD أن تكون أسماء اختبار الوحدة عبارة عن جمل كاملة تبدأ بفعل مشروط ("يجب" باللغة الإنجليزية على سبيل المثال) ويجب كتابتها حسب قيمة الأعمال. يجب كتابة اختبارات القبول باستخدام إطار رشيق قياسي لقصة المستخدم: " _كدور_ أريد _ميزة_ حتى تحقق _الفائدة_ ". يجب كتابة معايير القبول من حيث السيناريوهات وتنفيذها كطبقات: معطى _السياق الأولي_ ، عند _وقوع الحدث_ ، ثم _تأكد من بعض النتائج_ .
مثال
```
Story: Returns go to stock
As a store owner
In order to keep track of stock
I want to add items back to stock when they're returned.
Scenario 1: Refunded items should be returned to stock
Given that a customer previously bought a black sweater from me
And I have three black sweaters in stock.
When he returns the black sweater for a refund
Then I should have four black sweaters in stock.
Scenario 2: Replaced items should be returned to stock
Given that a customer previously bought a blue garment from me
And I have two blue garments in stock
And three black garments in stock.
When he returns the blue garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock.
```
جنبا إلى جنب مع بعض الفوائد:
1. يمكن تتبع كل أعمال التطوير مباشرة إلى أهداف العمل.
2. تطوير البرامج يلبي حاجة المستخدم. المستخدمون الراضين = عمل جيد.
3. تحديد الأولويات بكفاءة - يتم تسليم ميزات الأعمال الهامة أولاً.
4. جميع الأطراف لديها فهم مشترك للمشروع ويمكن أن تشارك في الاتصال.
5. تضمن اللغة المشتركة للجميع (سواء كانت تقنية أو غير ذلك) رؤية شاملة لتقدم المشروع.
6. تصميم البرامج الناشئ الذي يتطابق مع احتياجات الأعمال القادمة ويدعمها.
7. تحسين كود الجودة يقلل من تكاليف الصيانة ويقلل من مخاطر المشروع.
## معلومات اكثر
* ويكي على [BDD](https://en.wikipedia.org/wiki/Behavior-driven_development)
* ومن المعروف أن إطار تطوير السلوكيات المدفوعة (BDD) هو [الخيار](https://cucumber.io/) . يدعم الخيار العديد من لغات البرمجة ويمكن دمجه مع عدد من الأطر ؛ على سبيل المثال ، [Ruby on Rails](http://rubyonrails.org/) و [Spring Framework](http://spring.io/) و [Selenium](http://www.seleniumhq.org/)
* https://inviqa.com/blog/bdd-guide

29
guide/arabic/agile/build-measure-learn/index.md
View File

@ -1,29 +0,0 @@
---
title: Build Measure Learn
localeTitle: بناء التدبير التعلم
---
## بناء التدبير التعلم
حلقة البناء-القياس-التعلم هي طريقة تُستخدم لبناء المنتج المناسب. تمكّن هذه الحلقة ، التي تم اقتباسها في كتاب "بدء التشغيل المرن" من إريك ريس ، من إجراء التجارب السريعة ، بهدف وحيد هو تحقيق تناسب السوق. بمعنى آخر ، إنه نظام قوي للتحقق من صحة الافتراضات المتعلقة بالمنتج الذي حددته لتسليمه. كسر الحلقة ، يتكون من الأجزاء التالية:
![بناء تدبير تعلم حلقة](https://steveblank.files.wordpress.com/2015/05/ideas-build-code-measure.jpg)
### فكرة
تبدأ كل حلقة بفكرة توفر قيمة تجارية لبعض المستخدمين. يجب أن تتكون هذه الفكرة من رؤية للمنتج - والتي ستوجهك إلى ما يجب إنشاؤه ، ومقياسًا يشير إلى ما إذا كانت افتراضاتك حول قيمة العمل صحيحة.
### بناء
لإثبات صحة فكرتك ، تبدأ في إنشاء منتج قابل للتطبيق بحد أدنى (MVP) ، مقترنًا بمقاييس محددة مسبقًا (يفضل أحدها) ، والغرض منها هو التحقق من صحة نظريتك ، ومساعدتك على تحديد ما إذا كان عليك الحفاظ على أو التدوير.
### قياس
تركز هذه المرحلة على جمع البيانات والمقاييس من MVP.
### تعلم
بعد ذلك ، باستخدام البيانات التي تم جمعها ، يجب اتخاذ قرار ، سواء كان المستخدم يستخدم المنتج أم لا ، ومن ثم يجب عليك الحفاظ عليه ، أو ما إذا كان المستخدمون غير مهتمين بالمنتج ، وعلى هذا النحو يجب أن تقوم بالدوران. وبالتالي تنتهي مرحلة التعلم بفكرة (إما كيفية توسيع نطاق المنتج ، أو كيفية التدوير من المنتج الأصلي) ، والتي تنطبق على حلقة البناء التدريبي التالي.
#### معلومات اكثر:
[لماذا نبني ، نقيس ، نتعلم - لا نقوم فقط برمي الأشياء ضد الجدار لنرى ما إذا كانت تعمل - المنتج الحد الأدنى القابل للتطبيق](https://steveblank.com/2015/05/06/build-measure-learn-throw-things-against-the-wall-and-see-if-they-work/) [حلقة تعليقات تقييم البناء-تعلم](https://www.mindtools.com/pages/article/build-measure-learn.htm)

21
guide/arabic/agile/burndown-charts-and-burnup-charts/index.md
View File

@ -1,21 +0,0 @@
---
title: Burndown Charts and Burnup Charts
localeTitle: Burndown Charts و Burnup Charts
---
## Burndown Charts و Burnup Charts
تُستخدم مخططات الإحتراق والإنهيار لقياس مدى تقدم مشروع ما - عادةً ما يكون سباقًا سريعًا ضمن منهجية أجيل. كل من الرسوم البيانية تمثل بصريا العمل مقابل الوقت.
توضح مخططات Burndown مقدار العمل المتبقي مقابل مقدار الوقت المتبقي. يمثل المحور Y العمل المتبقي الذي يتعين القيام به - عادة ما يتعلق بتقدير الوقت المخصص لكل مهمة ، على سبيل المثال نقاط القصة - ويمثل المحور X الوقت المتبقي. يتم استخدام سطرين. أول - "خط العمل المثالي المتبقي" - يمثل حرق مثالي ، حيث يتم إنجاز كل يوم مقدار العمل المتناسب مع إجمالي الوقت ، مما يؤدي إلى خط مستقيم. يُستخدم "الخط المتبقي للعمل الفعلي" الثاني لرسم مخطط للتقدم الفعلي حيث تنتقل taks من خلال التطوير إلى الحالة المنجزة. ويرد مثال على مخطط احترق أدناه.
![alt text](https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png "مصدر الصورة: ويكيبيديا")
تستخدم العديد من فرق Scrum مخططات حرق من أجل معرفة كيف يفعلون أثناء العدو. قد يكون وجود حرق متوازن ومستقر مؤشراً على أن القصص صغيرة ويمكن التحكم فيها. إذا لاحظ فريق في منتصف سباق أن "خط العمل الفعلي المتبقي" فوق "خط العمل المثالي المتبقي" ، يمكنهم إجراء تعديلات على النطاق: يمكن إخراج القصص من العجلة أو يمكن أن يكون نطاق القصص جعل أصغر. قد يؤدي النظر إلى الاحتراق أثناء عملية البحث بأثر رجعي في نهاية السباق إلى إثارة بعض المناقشات المثيرة للاهتمام والنتيجة لتحسين العملية.
تشبه المخططات الإنشائية للغاية ، ولكنها تُظهر العمل الذي تم إنجازه مقابل إجمالي مبلغ العمل والوقت المتبقي. يتم استخدام ثلاثة خطوط - خط مثالي ، خط عمل مكتمل ، وخط عمل كامل. في هذا المخطط ، يجب أن يكون خط العمل الكلي ثابتًا إلى حد ما في أعلى المخطط ، ويعد تمثيلًا جيدًا لتغيير النطاق. يجب أن ينتقل خط العمل المكتمل بثبات نحو خط العمل الإجمالي لمقدار الوقت في المشروع - يظهر مساره المثالي من خلال الخط المثالي. ويرد أدناه مثال على ذلك.
![alt text](https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAljAAAAJGQ1ZDI2NzRkLWExYTQtNGI2OS1hZmZjLTM1NGMzYTk1NTEyNg.png "مصدر الصورة: علاء البحيري ، ينكدين")
#### معلومات اكثر:
[Burndown Charts- ويكيبيديا](https://en.wikipedia.org/wiki/Burn_down_chart) [تحترق مقابل حرق الرسم البياني - ينكدين](https://www.linkedin.com/pulse/burn-up-vs-down-chart-alaa-el-beheri-cisa-rmp-pmp-bcp-itil/)

11
guide/arabic/agile/business-value/index.md
View File

@ -1,11 +0,0 @@
---
title: Business Value
localeTitle: قيمة العمل
---
## قيمة العمل
قيمة الأعمال هي محور التسليم أجايل. يتم تكليف فريق أجايل بتقييم قيمة العمل لجميع الأعمال.
القيمة التجارية تصف ما سيحصل عليه العميل لجزء محدد من العمل.
يتم اكتشاف هذه القيمة من خلال المحادثات مع العميل وتحليل العمل المتضمن. قد يكون لأصحاب المصلحة التجاريين البيانات التي تحدد قيمة ميزة معينة تم طلبها. سيستخدم مالك المنتج المصادر المختلفة للمعلومات المتاحة ويخصص وقتًا كبيرًا لفهم وتقييم وتحديد أولوية القيمة التي سيتلقاها العميل في عمل معين.

18
guide/arabic/agile/chickens-versus-pigs/index.md
View File

@ -1,18 +0,0 @@
---
title: Chickens Versus Pigs
localeTitle: الدجاج في مقابل الخنازير
---
## الدجاج في مقابل الخنازير
يشير "الدجاج مقابل الخنازير" إلى قصة حول الدجاج والخنزير ، حيث يقترح الدجاج فتح مطعم يسمى "Ham-n-Eggs". يرفض الخنزير ، لأنه في حين أن الدجاج يحتاج فقط إلى وضع البيض ، فإن الخنزير لديه الكثير على المحك.
في مشروع تطوير البرمجيات Agile ، مطور البرامج هو الخنزير. إذا فشلت في إكمال المهمة ، أو فشلت في القيام بها بشكل جيد ، لديك الكثير على المحك. هذا يمكن أن يكون سمعتك ، أو ربما حتى موقفك. قد يتم أيضًا اعتبار أعضاء الفريق الآخرين الخنازير ، اعتمادا على مقدار ما لديهم على المحك.
من ناحية أخرى ، العديد من أعضاء الفريق هم الدجاج. على سبيل المثال ، لن يتأثر العميل أو مدير المشروع عالي المستوى بسبب فشل المشروع. إنهم مهتمون بنجاحها ، وقد يقدمون مساهمات ، ولكن لديهم حصص أقل وبالتالي لديهم التزام أقل بشكل ملحوظ بالمشروع.
يجب أن تجاهد لتكون خنزير بدلاً من دجاج. يمكنك الاستفادة من (ولكن لا ينبغي الاعتماد على) الدجاج من أجل تقليل المخاطر و ضمان تسليم المشروع بأكبر قدر ممكن من الكفاءة.
#### معلومات اكثر:
[رشيقة جدي: قصة الدجاج والخنزير](http://www.agilejedi.com/chickenandpig)
[ويكيبيديا: الدجاج والخنزير](https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig)

23
guide/arabic/agile/code-smells/index.md
View File

@ -1,23 +0,0 @@
---
title: Code Smells
localeTitle: قانون الروائح
---
## قانون الروائح
تعتبر "رائحة الشمعة" في برمجة الكمبيوتر مؤشراً سطحياً على أنه قد تكون هناك مشكلة فيما يتعلق بنظامك وجودة التعليمات البرمجية الخاصة بك. قد تتطلب هذه المشكلة إعادة بيعها ليتم إصلاحها.
من المهم أن نفهم أن الشفرة كريهة الرائحة تعمل ، لكنها ليست ذات نوعية جيدة.
#### أمثلة
1. رمز مكرر - كتل من التعليمات البرمجية التي تم نسخها نسخاً متماثلاً عبر قاعدة التعليمات البرمجية. قد يشير ذلك إلى أنك تحتاج إلى تعميم الشفرة في وظيفة واستدعاءها في مكانين ، أو قد يكون الطريقة التي تعمل بها الشفرة في مكان واحد غير مرتبطة تمامًا بالطريقة التي تعمل بها في مكان آخر ، على الرغم من نسخها.
2. فصول كبيرة - فئات تحتوي على عدد كبير جدًا من أسطر الشفرة. قد يشير هذا إلى أن الفصل يحاول القيام بأشياء كثيرة جدًا ، ويجب تقسيمه إلى فئات أصغر.
#### معلومات اكثر:
* _إعادة بيع ديون: تحسين تصميم المدونة الحالية - كنت بيك ، مارتن فاولر_
* _كود النظيفة: دليل للأعمال الحرفية رشيقة - مارتن ، روبرت C. (2009)._
* [قانون الروائح على ويكيبيديا](https://en.wikipedia.org/wiki/Code_smell)
* [قانون الروائح على مدونة جيف اتوود (ترميز الرعب)](https://blog.codinghorror.com/code-smells/)
* [رمز الروائح على وارد Cunningham في C2 ويكي](http://wiki.c2.com/?CodeSmell)
* [مارتن فاولر - رمز الرائحة](https://martinfowler.com/bliki/CodeSmell.html)

10
guide/arabic/agile/colocation-vs-distributed/index.md
View File

@ -1,10 +0,0 @@
---
title: Collocation Vs Distributed
localeTitle: التجميع مقابل الموزعة
---
## التجميع مقابل الموزعة
* ويشير الموقع المشترك إلى فريق يجلس معًا ؛ نفس المكتب. من الناحية المثالية ، الجميع يجلسون معا في المكاتب المجاورة أو مساحة عمل مفتوحة.
* أعضاء الفريق الموزعة منتشرة جغرافيا. المباني المختلفة ، أو المدن ، أو حتى البلدان. في حالة الفريق الموزع ، يجب أن تسهل البنية التحتية العمليات من أجل حل فرق التوقيت والمسافة بين أعضاء الفريق ، وبالتالي توفير طريقة فعالة للعمل بشكل كامل.
#### معلومات اكثر:

9
guide/arabic/agile/continuous-delivery/index.md
View File

@ -1,9 +0,0 @@
---
title: Continuous Delivery
localeTitle: التسليم المستمر
---
## التسليم المستمر
يعد التسليم المستمر (CD) منهجًا هندسيًا للبرامج تقوم فيه فرق العمل بإنتاج البرامج في دورات قصيرة ، مما يضمن إمكانية إصدار البرنامج بشكل موثوق به في أي وقت. [1](https://en.wikipedia.org/wiki/Extreme_programming)
وهو يهدف إلى بناء واختبار وإصدار البرامج بشكل أسرع وأكثر تواتراً. يساعد هذا النهج على تقليل التكلفة والوقت ومخاطر تنفيذ التغييرات من خلال السماح بتحديثات متزايدة للتطبيقات في الإنتاج. تعتبر عملية النشر المباشرة والقابلة للتكرار مهمة للتسليم المستمر. التسليم المستمر يعني أن الفريق يضمن أن كل تغيير يمكن نشره للإنتاج ولكن قد يختار عدم القيام به ، عادةً بسبب أسباب العمل

13
guide/arabic/agile/continuous-deployment/index.md
View File

@ -1,13 +0,0 @@
---
title: Continuous Deployment
localeTitle: انتشار مستمر
---
## انتشار مستمر
يعد النشر المستمر عملية هندسة برمجية حديثة والتي تعتبر جزءًا من بيئة DevOps. وهي تتضمن فرقًا من المطورين الذين يقومون بإنتاج وتحديث وإصدار الكود في دورات قصيرة جدًا. هذا يعني أن المطورين يرتكبون كميات صغيرة من الكود ، في كثير من الأحيان.
يتمثل الهدف من النشر المستمر في الحصول على تعليمات برمجية في حالة موثوقة وقابلة للنشر دائمًا لتمكين إصدار هذا الرمز في أي وقت. تهدف هذه العملية إلى إطلاق الشفرة بسرعة أكبر. لتحقيق النشر المستمر ، يعتمد فريق التطوير على البنية التحتية التي تعمل على أتمتة الخطوات المختلفة التي تؤدي إلى النشر. وغالبًا ما يطلق على هذا اسم البنية التحتية كدليل (IaC).
تشتمل فائدتان رئيسيتان للنشر المستمر على عائد سابق على الاستثمار لكل ميزة بعد تطويرها بسبب أوقات الإصدار الأقل بالإضافة إلى التعليقات السابقة على الميزات الجديدة.
وتتضمن المزايا الأخرى للنشر المستمر تحسين جودة الشفرة نظرًا لحدوث أخطاء أقل مما يجعلها أكثر إنتاجًا وإصدارًا موثوقًا للشفرات ووقتًا أقل بكثير للتسويق.

60
guide/arabic/agile/continuous-integration/index.md
View File

@ -1,60 +0,0 @@
---
title: Continuous Integration
localeTitle: التكامل المستمر
---
## التكامل المستمر
في التكامل الأساسي الأكثر أهمية (CI) هو منهجية تطوير رشيقة يقوم فيها المطورون بدمج التعليمات البرمجية الخاصة بهم بشكل منتظم إلى المصدر الرئيسي ، عادةً فرع `master` بعيد. من أجل ضمان عدم إدخال أي تغييرات في التكسير ، يتم تشغيل مجموعة اختبار كاملة على كل بنية حيادية لاختبار الانحدار الجديد ، أي اختبار أن الشفرة الجديدة لا تكسر الميزات الحالية القائمة.
يتطلب هذا النهج اختبارًا جيدًا لقاعدة الرمز ، مما يعني أن أغلبية الشفرة ، إن لم يكن جميعها ، لديها اختبارات تضمن أن ميزاتها تعمل بكامل طاقتها. سوف يمارس التكامل المستمر بشكل مثالي مع [التطوير](https://guide.freecodecamp.org/agile/test-driven-development) الكامل [القائم على الاختبار](https://guide.freecodecamp.org/agile/test-driven-development) .
### الخطوات الرئيسية
الخطوات الأساسية التالية ضرورية لأداء الأسلوب الحالي الأكثر القياسية للتكامل المستمر.
1. الحفاظ على الريبو المركزي وفرع `master` نشط.
يجب أن يكون هناك مستودع رمز للجميع للاندماج في وسحب التغييرات من. هذا يمكن أن يكون على جيثب أو أي عدد من خدمات تخزين الأكواد.
2. أتمتة البناء.
استخدام البرامج النصية الآلية الوقائية الوطنية أو بناء أدوات أكثر تعقيدا مثل الغزل، النخير، Webpack، أو [بلع](https://guide.freecodecamp.org/developer-tools/gulp) ، أتمتة البناء بحيث قيادة واحدة يمكن بناء نسخة تعمل بشكل كامل من المنتج، وعلى استعداد لنشرها في بيئة الإنتاج. الأفضل من ذلك ، يمكنك تضمين النشر كجزء من البنية التلقائية!
3. جعل تشغيل بناء جميع الاختبارات.
للتحقق من عدم وجود أي شيء في التعليمة البرمجية الجديدة يكسر الوظائف الموجودة ، يجب تشغيل مجموعة الاختبار الكاملة ويجب أن تفشل البنية إذا فشلت أي اختبارات ضمنها.
4. يجب على الجميع دمج التغييرات `master` كل يوم.
5. كل عملية دمج `master` يجب أن يتم بناؤها واختبارها بالكامل.
### أفضل الممارسات
هناك المزيد من أفضل الممارسات التي تستخدم أفضل ما تقدمه CI والتحديات التي تقدمها ، مثل:
1. حافظ على سرعة الإنشاء ، بحيث لا يتم إهدار الكثير من وقت التطوير في انتظار الإنشاء.
2. اختبار البنية في نسخة كاملة من بيئة الإنتاج.
إذا كان لديك ، على سبيل المثال ، تطبيقًا تم نشره على شيء ما مثل Heroku أو Digital Ocean ، فبإمكانك إجراء اختبار منفصل هناك يمكنك من خلاله نشر اختبارات ، للتأكد من أنها لا تعمل فقط في الاختبارات ولكن في بيئة إنتاج حقيقية. يجب أن تكون بيئة الاختبار هذه متطابقة وظيفياً مع بيئة الإنتاج الفعلية ، وذلك لضمان دقة الاختبار.
3. اجعل من السهل البقاء على اطلاع دائم.
يجب على الكوداء السحب بانتظام من الفرع `master` للحفاظ على دمج رمزهم مع التغييرات من فريقهم. يجب أيضًا إتاحة الريبو لأصحاب المصلحة مثل مديري المنتجات ، أو مديري الشركات ، أو العملاء الرئيسيين في بعض الأحيان ، بحيث يكون الجميع قادرين على رؤية التقدم بسهولة.
4. احتفظ بسجلات للبنود ، بحيث يمكن للجميع الاطلاع على نتائج أي بنية معينة ، سواء نجحت أو فشلت ، ومن أو ما أدخل تغييرات جديدة.
5. أتمتة النشر.
حافظ على تحديث تطبيقك تمامًا مع أي تغييرات جديدة عن طريق أتمتة النشر في بيئة الإنتاج كمرحلة أخيرة من عملية الإنشاء ، بعد اجتياز جميع الاختبارات ونجاح عملية اختبار الاختبار في استنساخ بيئة الإنتاج.
### خدمات CI
توجد الكثير من الخدمات للتعامل مع عملية التكامل المستمر بالنسبة لك ، والتي يمكن أن تجعل من السهل إنشاء خط أنابيب CI صلب أو عملية بناء. عند تقييم ذلك ، ضع في اعتبارك عوامل مثل الميزانية وسرعة الإنشاء ونوع المشروع الذي تعمل عليه. تقدم بعض الخدمات ، مثل [Travis CI](https://travis-ci.org) خدمات مجانية للمشروعات مفتوحة المصدر ، والتي يمكن أن تجعلها خيارًا سهلاً لمشاريع كهذه ، ولكن قد يكون لها أبطأ من الخدمات الأخرى ، مثل [Circle CI](https://circleci.com/) أو [Codeship](https://codeship.com/) ، على سبيل المثال لا الحصر.
#### معلومات اكثر:
إدخال ويكيبيديا في [التكامل المستمر](https://en.wikipedia.org/wiki/Continuous_integration) .

44
guide/arabic/agile/cross-functional-teams/index.md
View File

@ -1,44 +0,0 @@
---
title: Cross Functional Teams
localeTitle: فرق متعددة الوظائف
---
## فرق متعددة الوظائف
فريق متعدد الوظائف هو مجموعة من الأشخاص ذوي خبرات وظيفية مختلفة يعملون نحو هدف مشترك.
عادةً ما تتضمن الموظفين من جميع مستويات المؤسسة. قد يأتي الأعضاء أيضًا من خارج المؤسسة (على وجه الخصوص ، من الموردين أو العملاء الرئيسيين أو الاستشاريين). تعمل الفرق المتقاطعة في كثير من الأحيان كفرق ذاتية التوجيه مخصصة لمهمة محددة تستدعي مدخلات وخبرات العديد من الإدارات.
إن تعيين مهمة لفريق يتكون من أفراد متعددي التخصصات يزيد من مستوى الإبداع والتفكير خارج الصندوق.
يقدم كل عضو وجهة نظر بديلة للمشكلة والحل المحتمل لهذه المهمة. في عالم الأعمال اليوم ، يعد الابتكار ميزة تنافسية رائدة ، وتشجع الفرق متعددة الوظائف الابتكار من خلال عملية تعاون خلاقة. يجب أن يكون أعضاء فريق متعدد الوظائف على دراية كبيرة في تعدد المهام لأنهم مسؤولون في نفس الوقت عن واجبات فريقهم الوظيفية المتقاطعة بالإضافة إلى مهام العمل اليومية المعتادة.
### هدف مشترك
* الأفضل للفريق ، أفضل للفرد
* تحسين التنسيق والتكامل
* العمل عبر حدود orgnisational
* تحسين كفاءة الفريق من خلال زيادة الإنتاجية
* تحقيق رضا العملاء بالعمل على نفس الهدف
وقد رأى بعض الباحثين أن التفاعلات متعددة الوظائف ذات طبيعة تعاونية أو تنافسية ، في حين جادل آخرون بأن المجالات الوظيفية للمنظمة غالبًا ما تُجبر على التنافس والتعاون في وقت واحد مع بعضها البعض ("coetition") ومن الأهمية بمكان فهم كيفية تفاعل هذه العلاقات المعقدة. وتؤثر على أداء الشركة.
### عبر فريق وظيفي تكوين المهارات
يتمثل أحد التحديات الشائعة في تكوين الفرق الوظيفية المتقاطعة في فكرة أنه يجب على كل عضو تقني في الفريق امتلاك جميع المهارات الفنية اللازمة لأداء أي عمل من الأعمال. من المفيد أن يقوم أعضاء الفريق بأداء أكثر من مهارة فنية واحدة ولكن لا يزال من الجيد وجود متخصصين. الأمر أفضل عندما لا يكون جميع أعضاء الفريق متخصصين.
#### معلومات اكثر:
* [17 الوسائل التي تمكّن من الاستفادة من فريق العمل المختلط](https://www.scoro.com/blog/improve-cross-team-collaboration/)
* [11 أسباب لاستخدام فرق وظيفية عبر](https://blog.kainexus.com/employee-engagement/cross-functional-collaboration/cross-functional-teams/11-reasons)
* [فرق Scrum وظيفية](https://www.scrumalliance.org/community/articles/2014/june/success-story-cross-functional-scrum-teams)
* [عبر وظيفة لا يعني الجميع يمكن أن يفعل كل شيء](https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything)
* [فرق متعددة الوظائف](https://dzone.com/articles/cross-functional-scrum-teams)

28
guide/arabic/agile/crystal/index.md
View File

@ -1,28 +0,0 @@
---
title: Crystal
localeTitle: كريستال
---
## كريستال
إنها منهجية تعد أسلوبًا خفيفًا وقابلاً للتكيف مع تطوير البرامج. وهي عائلة من المنهجيات الرشيقة التي تتضمن الكريستال واضحة ، كريستال أصفر ، كريستال أورانج وغيرها. أي منهم لديه سمة فريدة من نوعها مدفوعة بالعديد من العوامل ، مثل حجم الفريق ، ومدى أهمية النظام وأولويات المشروع. والذي ينص على أن كل مشروع قد يحتاج إلى مجموعة مختلفة من الممارسات والقواعد والعمليات وفقًا لخصائص المشروع الفريدة. تم تطويرها جميعًا بواسطة أليستير كوكبورن في التسعينات.
ووفقا له ، يتم تعريف وجوه الكريستال بأنها المنهجية والتقنيات والسياسات
المنهجية - العناصر التي هي جزء من المشروع التقنيات - مجالات المهارات السياسات - تنظيمات لا تفعل ولا
تركز هذه الأساليب على:
1. اشخاص
2. التفاعل
3. تواصل اجتماعي
4. مهارات
5. المواهب
6. مجال الاتصالات
! \[ألوان مختلفة\] https://upload.wikimedia.org/wikiversity/en/c/c5/Crystal _Family_ example.jpg
يتطلب الأمر ضربات مختلفة لتحريك العالم ، ووفقا لكريستال ، فإنه يأخذ ألوان مختلفة لتحريك المشروع.
#### معلومات اكثر:
\[مقالة Wikiiversity\] https://en.wikiversity.org/wiki/Crystal\_Methods

15
guide/arabic/agile/customer-units/index.md
View File

@ -1,15 +0,0 @@
---
title: Customer Units
localeTitle: وحدات العملاء
---
## وحدات العملاء
في Agile ، وحدات العملاء هي الأشخاص والدور الذي يمثل الصوت ، والتوقعات من العملاء / السوق المستهدفة من قبل المنتج.
وحدات العملاء المسؤولة عن منتج تجربة المستخدم ، رؤية للمنتج ، خريطة طريق المنتج ، إنشاء تراكمات المنتج والحفاظ عليها ، وأي شيء.
مثال الشخص / الأدوار: -> مديري المنتج -> مبيعات -> تسويق -> المستخدم النهائي
#### معلومات اكثر:
وحدة العميل: [الحلول](https://www.solutionsiq.com/agile-glossary/customer-unit/)

27
guide/arabic/agile/daily-standup-and-daily-scrum/index.md
View File

@ -1,27 +0,0 @@
---
title: Daily Stand-Up and Daily Scrum
localeTitle: Daily Stop-Up و Daily Scrum
---
## Daily Stop-Up و Daily Scrum
الاجتماع اليومي (DSU) أو اجتماع Daily Scrum هو أحد الأجزاء الأساسية لمنهجية scrum.
كما يوحي الاسم ، يمكنك عقد الاجتماع يوميًا ، وفي الوقت نفسه ، وفي نفس الوقت بالنسبة لفريق مشترك في الموقع. يجب أن يكون الاجتماع مختصراً ، وينتهي في أقل من 15 دقيقة.
مطلوب فقط من أعضاء فريق التطوير حضور Daily Stand-up. عادةً ، سيحضر أيضًا Scrum Master ومالكو المنتج ، لكنهم غير مطلوبين.
الأجندة الموحدة لكل شخص هي:
* ماذا فعلت منذ DSU الماضي
* ماذا تفعل بعد هذا DSU
* ما هي العقبات الرئيسية التي تقف في طريق تقدمك ، وأين تحتاج إلى المساعدة
يتعين على أعضاء الفريق الإصغاء بعناية لمساهمات بعضهم البعض ومحاولة تحديد المجالات التي يمكنهم فيها مساعدة تقدم بعضهم البعض. كما سيطرح الاجتماع الاحتياطي على مزيد من الموضوعات المطولة للمناقشة والتي يجب أن تتم بين مختلف أعضاء الفريق. وينبغي عندئذ إيقاف هذه المناقشات المطولة التي تنشأ ، وتتخذ خارج المواجهة ، التي تشمل المشاركين ذوي الصلة فقط ، وليس الفريق بأكمله.
### مثال على اجتماع الوقوف
https://www.youtube.com/watch؟v=\_3VIC8u1UV8
### معلومات اكثر:
اجتماع الوقوف: [ويكيبيديا](https://en.wikipedia.org/wiki/Stand-up_meeting)

17
guide/arabic/agile/delivery-team/index.md
View File

@ -1,17 +0,0 @@
---
title: Delivery Team
localeTitle: فريق التسليم
---
## فريق التسليم
يتكون فريق scrum من مالك المنتج (PO) ، و Scrum Master (SM) ، وفريق التسليم.
فريق التوصيل هو كل شخص باستثناء PO و SM ؛ المطورين ، واختبار ، ومحللي النظم ، ومحللي قواعد البيانات ، والمحللين UI / UX ، وهلم جرا.
ولكي يكون فريق توصيل سكروم فعالا ، يجب أن يكون ذكيا (أو رشيقة!) بما فيه الكفاية حتى يتم الاتفاق على القرارات بسرعة بينما تكون متنوعة بما فيه الكفاية بحيث يمكن للفريق بأكمله تغطية الغالبية العظمى من المواصفات المطلوبة لتطوير البرمجيات. من الناحية المثالية ، يعمل فريق بين 3 و 9 أشخاص بشكل عام بشكل جيد لفريق تطوير سكروم.
يجب على الفريق أيضا تعزيز الاحترام المتبادل من خلال كل عضو من أعضاء الفريق. سيتمكن فريق scrum الفعال من مشاركة عبء العمل ووضع إنجازات الفريق قبل إنجازات الفرد.
#### معلومات اكثر:
مقال التمهيدي في Atlassian على سكروم [هنا.](https://www.atlassian.com/agile/scrum)

31
guide/arabic/agile/design-patterns/index.md
View File

@ -1,31 +0,0 @@
---
title: Design Patterns
localeTitle: أنماط التصميم
---
## أنماط التصميم
نمط التصميم هو حل تصميم شائع لمشكلة التصميم الشائعة. تسمى مجموعة أنماط التصميم الخاصة بمجال أو مجال ذي صلة بلغة النمط. لاحظ أن هناك أيضًا أنماطًا في مستويات أخرى: رمز ، التزامن ، الهندسة المعمارية ، تصميم التفاعل ...
في هندسة البرمجيات ، يعتبر نمط تصميم البرمجيات حلاً عامًا قابلاً لإعادة الاستخدام لمشكلة شائعة في سياق معين في تصميم البرامج. إنه ليس تصميمًا نهائيًا يمكن تحويله مباشرة إلى شفرة المصدر أو الآلة. هو وصف أو قالب لكيفية حل مشكلة يمكن استخدامها في العديد من المواقف المختلفة. أنماط التصميم هي أفضل الممارسات الرسمية التي يمكن للمبرمج استخدامها لحل المشاكل الشائعة عند تصميم تطبيق أو نظام.
عادةً ما تُظهر أنماط التصميم الموجهة للكائنات العلاقات والتفاعلات بين الفئات أو الكائنات ، دون تحديد فئات التطبيق النهائية أو الكائنات المتضمنة. قد تكون الأنماط التي تشير إلى حالة قابلة للتغيير غير مناسبة للغات البرمجة الوظيفية ، يمكن أن تكون بعض الأنماط غير ضرورية في اللغات التي تحتوي على دعم مدمج لحل المشكلة التي تحاول حلها ، وأن الأنماط الموجهة للكائنات ليست بالضرورة مناسبة لغير الكائن لغات مستقيمة.
قد يتم النظر إلى أنماط التصميم كنهج منظم لبرمجة الكمبيوتر الوسيطة بين مستويات نموذج البرمجة وخوارزمية ملموسة.
إن الكتاب الذي جعل هذا الحقل مشهوراً في هذا المجال ، هو " **أنماط تصميم** جانج أوف فور" (GoF) **: عناصر البرامج الموجهة التي يمكن إعادة استخدامها** (1994). تقدم سلسلة (23) من الأنماط لغة OO (C ++) التقليدية المصنفة في ثلاثة أنواع:
* **خلق** (لإنشاء كائنات): مصنع مجردة ، باني ، طريقة المصنع ، النموذج ، المفرد.
* **الهيكلية** (لتأليف الأشياء): محول ، جسر ، مركب ، ديكور ، واجهة ، ذبابة ، وكيل.
* **السلوكية** (للتواصل بين الكائنات): سلسلة من المسؤولية ، الأمر ، المفسر ، المكرر ، الوسيط ، المذكرات ، المراقب ، الحالة ، الإستراتيجية ، طريقة القالب ، الزائر.
يمكن استخدام الأنماط لأهداف متعددة (التعلم ، التواصل ، تحسين الأدوات الخاصة بك) ولكن في رشيقة يجب أن يتم إعادة تشكيلها من الكود مع دين تقني وليس فقط إضافتها في البداية (تصميم / هندسة معمارية طارئة) كما في البداية ليس لديك معرفة كافية حول النظام (المستقبلي) الذي سوف يتطور. لاحظ أن ما يتطلب وجود نمط بلغة أو أداة قد لا يكون مطلوبًا أو قد يكون بالفعل جزءًا من لغة أو أداة أخرى. الإطار هو مجموعة من الطبقات المتعاونة التي تشكل تصميمًا قابلًا لإعادة الاستخدام لنوع معين من البرامج وعادة ما تكون ثقيلة النمط.
#### معلومات اكثر:
* [ويكيبيديا على أنماط التصميم](https://en.wikipedia.org/wiki/Software_design_pattern)
* [ويكيبيديا على GoF كتاب](https://en.wikipedia.org/wiki/Design_Patterns)
* [أنماط التصميم حسب صنع المصدر](https://sourcemaking.com/design_patterns) : قائمة الأنماط المعروفة المتوفرة على الإنترنت
* [أنماط برمجة اللعبة](http://gameprogrammingpatterns.com/) : كتاب عن أنماط التصميم المستخدمة بشكل شائع في تطوير الألعاب ، وهي متاحة للقراءة على الإنترنت مجانًا
* [التصميم الموجه للكائن](http://www.oodesign.com/)
* [دليل المبتدئين لأنماط التصميم](https://code.tutsplus.com/articles/a-beginners-guide-to-design-patterns--net-12752)
* [من أنماط التصميم إلى نظرية الفئات](http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/)

22
guide/arabic/agile/dsdm/index.md
View File

@ -1,22 +0,0 @@
---
title: DSDM
localeTitle: DSDM
---
## DSDM
DSDM لتقف على طريقة تطوير النظم الديناميكية. إنها منهجية التطور السريع السريع ، وتهدف إلى معالجة المشكلة المستمرة لطول المدة التي يستغرقها تطوير نظم المعلومات. DSDM هو إطار عمل أكثر من طريقة محددة بدقة ، والكثير من التفاصيل حول كيفية القيام بالأمور في الواقع يتم تركها لمؤسسة تطوير البرمجيات أو الفرد لاتخاذ القرار. تتبنى DSDM مقاربة تدريجية وتستخدم مفهوم RAD (التطوير السريع للتطبيق) لل timeboxing. كما أنه يؤكد على الدور الرئيسي للناس في عملية التنمية ويوصف بأنه نهج يركز على المستخدم.
يحتوي DSDM على 9 مبادئ أساسية ، على النحو التالي:
1) مشاركة المستخدم النشطة أمر حتمي. 2) يجب تمكين الفرق من اتخاذ القرارات. المتغيرات الرئيسية الأربعة للتمكين هي: السلطة والموارد والمعلومات والمساءلة. 3) التسليم المتكرر للمنتجات أمر ضروري. 4) اللياقة البدنية لغرض العمل هو المعيار الأساسي لقبول التسليمات. 5) التطوير التكراري والتزايدي ضروري للتلاقي على حل تجاري دقيق. 6) جميع التغييرات التي تطرأ أثناء التطوير قابلة للانعكاس (أي أنك لا تمضي قدمًا في مسار معين إذا واجهتك مشاكل ؛ يمكنك الرجوع إلى آخر نقطة آمنة أو متفق عليها ، ثم البدء في مسار جديد). 7) المتطلبات الأساسية على مستوى عال (أي متطلبات الأعمال رفيعة المستوى ، بمجرد الاتفاق عليها ، مجمدة). هذا هو في جوهره نطاق المشروع. 8) يتم دمج الاختبار طوال دورة الحياة (أي اختبار أثناء التنقل بدلاً من الاختبار فقط في النهاية حيث يتم ضغطه بشكل متكرر). 9) من الضروري اتباع نهج تعاوني وتعاوني بين جميع أصحاب المصلحة.
المراحل الرئيسية الخمسة لدورة تطوير DSDM هي:
1) دراسة الجدوى. 2) دراسة الأعمال. 3) تكرار النموذج الوظيفي. 4) تصميم النظام وبناء التكرار. 5) التنفيذ.
#### معلومات اكثر:
يمكنك قراءة الروابط التالية لمعرفة المزيد.
* [Agile Business - ما هو DSDM؟](https://www.agilebusiness.org/what-is-dsdm)
* [ويكيبيديا - طريقة تطوير النظم الديناميكية](https://en.wikipedia.org/wiki/Dynamic_systems_development_method)

17
guide/arabic/agile/epics/index.md
View File

@ -1,17 +0,0 @@
---
title: Epics
localeTitle: الملاحم
---
## الملاحم
الملحمة هي عبارة عن قصة مستخدم كبيرة لا يمكن تسليمها على النحو المحدد ضمن عملية تكرار واحدة أو كبيرة بما فيه الكفاية بحيث يمكن تقسيمها إلى قصص مستخدمين أصغر. تغطي الملاحم عادة شخصية معينة وتعطي فكرة عامة عما هو مهم بالنسبة للمستخدم. يمكن تقسيم الملحمة إلى قصص مستخدم متعددة تعرض مهام فردية يرغب الشخص / المستخدم في أدائها.
لا يوجد نموذج قياسي لتمثيل الملاحم. تستخدم بعض الفرق تنسيقات القصص المألوفة للمستخدم (كما أ ، أريد ذلك ، لذا أو من أجل ، أ ، أريد) بينما تمثل الفرق الأخرى الملاحم بعبارة قصيرة.
* في حين أن القصص التي تضم ملحمة يمكن أن تكتمل بشكل مستقل ، فإن قيمة أعمالهم لم تتحقق حتى اكتمال الملحمة بأكملها
### مثال ملحمي
في تطبيق ما يساعد الرسامين المستقلين على تتبع مشاريعهم ، يمكن أن تكون ملحمة محتملة.
يرغب Paul the Painter في الحصول على طريقة أسهل لإدارة مشاريعه وتزويد موكله بتغييرات دقيقة وفاتورة.

15
guide/arabic/agile/extreme-programming/index.md
View File

@ -1,15 +0,0 @@
---
title: Extreme Programming
localeTitle: البرمجة المتطرفة
---
## البرمجة المتطرفة
البرمجة المتطرفة (XP) هي منهجية لتطوير البرمجيات تهدف إلى تحسين جودة البرامج والاستجابة لمتطلبات العملاء المتغيرة. [1](https://en.wikipedia.org/wiki/Extreme_programming)
الميزة الأساسية ل XP هي أن العملية برمتها مرئية وقابلة للمساءلة. سوف يقدم المطورون التزامات ملموسة حول ما سيحققونه ، وإظهار تقدم ملموس في شكل برامج قابلة للنشر ، وعندما يتم الوصول إلى نقطة تحول ، سيصفون بالضبط ما فعلوه وكيف ولماذا يختلف عن الخطة. وهذا يسمح للأشخاص الموجهين نحو الأعمال التجارية بالوفاء بالتزاماتهم التجارية الخاصة بهم بثقة ، والاستفادة من الفرص عند ظهورهم ، والقضاء على الطرق المسدودة بسرعة وبتكلفة منخفضة. [2](http://wiki.c2.com/?ExtremeProgramming) - كنت بيك
[![XP-ردود الفعل](https://upload.wikimedia.org/wikipedia/commons/4/44/XP-feedback.gif)](https://commons.wikimedia.org/wiki/File%3AXP-feedback.gif "بواسطة DonWells (عمل خاص) [CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)] ، عبر ويكيميديا ​​كومنز")
#### معلومات اكثر:
[قواعد البرمجة المتطرفة](http://www.extremeprogramming.org/rules.html)

13
guide/arabic/agile/feature-based-planning/index.md
View File

@ -1,13 +0,0 @@
---
title: Feature Based Planning
localeTitle: تخطيط قائم على الميزة
---
## تخطيط قائم على الميزة
يُعد **التخطيط استنادًا إلى ميزة** هي منهجية تخطيط يمكن استخدامها لتحديد متى يتم إصدار البرامج استنادًا إلى الميزات التي سيتم تسليمها للعملاء ، بدلاً من إصدار نهائي يعتمد على الموعد النهائي.
في هذه الطريقة في تخطيط الإطلاق ، تقرر الفرق ما هي الميزة / الميزات التي يجب تحديد أولوياتها. استنادًا إلى نطاق هذه الميزات ، يمكن للفريق التنبؤ بموعد نشر الإصدار التالي.
#### معلومات اكثر:
[ميزة التنمية مدفوعة](https://en.wikipedia.org/wiki/Feature-driven_development)

32
guide/arabic/agile/five-levels-of-agile-planning/index.md
View File

@ -1,32 +0,0 @@
---
title: Five Levels of Agile Planning
localeTitle: خمسة مستويات من التخطيط الرشيق
---
## خمسة مستويات من التخطيط الرشيق
يجب أن يكون مالك المنتج على دراية بالمستويات الخمسة للتخطيط السريع:
* تحديد رؤية المنتج
* تحديد خريطة طريق المنتج
* تخطيط الإصدار
* تخطيط العدو
* المحاسبة لنتائج السكتات اليومية
التخطيط السريع دائمًا مستمر ويجب مراجعته كل ثلاثة أشهر على الأقل.
## موجز موجز من خمسة مستويات التخطيط الرشيق
1. رؤية المنتج: ما هي (ملخص الفوائد والميزات الرئيسية التي سيوفرها المنتج) ، من (أصحاب المصلحة) ، لماذا (الحاجة والفرصة) ، متى (جدولة المشروع وتوقعات الوقت) ، القيود وافتراضات (مخاطر المخاطر والتكلفة).
2. خارطة طريق المنتج: الإصدارات - التاريخ ، الموضوع / مجموعة الميزات ، الهدف ، مقاربة التطوير.
3. تخطيط الإصدار: التكرارات ، سعة الفريق ، القصص ، الأولوية ، الحجم ، التقديرات ، تعريف العمل.
4. تخطيط العدو: القصص - المهام ، تعريف العمل ، مستوى الجهد ، الالتزام
5. التخطيط اليومي: ماذا فعلت أمس؟ ماذا سأفعل اليوم؟ ما الذي يمنعني؟
#### معلومات اكثر:
[خمسة مستويات من التخطيط الرشيق](https://www.scrumalliance.org/why-scrum/agile-atlas/agile-atlas-common-practices/planning/january-2014/five-levels-of-agile-planning)

12
guide/arabic/agile/functional-managers/index.md
View File

@ -1,12 +0,0 @@
---
title: Functional Managers
localeTitle: المديرين الفنيين
---
## المديرين الفنيين
المدير الوظيفي هو شخص لديه سلطة إدارية على مجموعة من الأشخاص. تأتي هذه السلطة من الوضع الرسمي لذلك الشخص في المنظمة (على سبيل المثال ، مدير القسم ، مدير قسم الجودة ، مدير فريق التطوير). دور المديرين الوظيفيين يختلف عن مدراء المشاريع أو ScrumMasters وليس على أساس المشروع.
في المزيد من المنظمات رشيقة توجد نماذج مختلفة. غالباً ما يكون المدير الوظيفي مسؤولاً عن تطوير الأفراد في مجموعاتهم ، وتأمين ميزانيات ووقت للناس. ومع ذلك ، فهناك أيضًا بعض نماذج شركة Agile حيث يتم توزيع المهام التي يتم تعيينها عادةً إلى المديرين الفنيين على أدوار أخرى داخل المؤسسة (مثل نموذج Spotify مع القبائل والنقابات والفصول والكتائب).
في الخارج في عالم العمل التقليدي ، تنظم الشركات الناس في تسلسل هرمي. يتم تجميع الأشخاص الذين لديهم أدوار عمل مماثلة في مناطق وظيفية ويقودهم مدير وظيفي. المدير الوظيفي مسؤول بشكل عام عن توجيه ورفاه الموظفين الذين يقدمون تقاريرهم مباشرة إليها.
غالباً ما تعمل فرق المشاريع الرشيقة مع المديرين الفنيين الذين يسيطرون على الموارد التي يحتاجها الفريق لإنجاز العمل. مثال على ذلك هو العمل مع مدير وظيفي في المشتريات لتعيين شخص للعمل مع الفريق لشراء تراخيص البرامج.

19
guide/arabic/agile/index.md
View File

@ -1,19 +0,0 @@
---
title: Agile
localeTitle: ذكي
---
## ذكي
تطوير البرمجيات رشيق هو مجموعة من المنهجيات المستخدمة لإدارة فرق من المطورين. وهي تدعو إلى التخطيط التكيفي ، والتطوير التطوري ، والتسليم المبكر ، والتحسين المستمر ، وتشجع على الاستجابة السريعة والمرنة للتغيير. يعتبر الناس والتواصل أكثر أهمية من الأدوات والعمليات.
تؤكد Agile على مطالبة المستخدمين النهائيين بما يريدون ، وكثيراً ما تعرض لهم عروض تجريبية للمنتج أثناء تطويره. وهذا يتناقض مع مقاربة "الشلال" ، والتنمية المدفوعة بالمواصفات ، وما يسميه ممارسو أجيليل "التصميم الكبير الأمامي". في هذه الطرق ، يتم تخطيط الميزات ووضعها في الميزانية قبل بدء التطوير.
مع Agile ، يكون التركيز على "الرشاقة" - القدرة على الاستجابة السريعة للتعليقات من المستخدمين والظروف المتغيرة الأخرى.
![فيلم كوميدي من Commitstrip.com يعرض مدير منتج يشرح للمطور أنه يتحول إلى رشيقة ، ولكن يطلب من المطور أن يخطط لكل شيء في المقدمة](https://www.commitstrip.com/wp-content/uploads/2017/01/Strip-Budegt-fixe-pour-projet-flexible-english650-final.jpg)
هناك العديد من النكهات المختلفة من الرشاقة ، بما في ذلك Scrum والبرمجة المتطرفة.
### معلومات اكثر
[Agile Alliance's Homepage](https://www.agilealliance.org/)

22
guide/arabic/agile/integration-hell/index.md
View File

@ -1,22 +0,0 @@
---
title: Integration Hell
localeTitle: التكامل الجحيم
---
## التكامل الجحيم
Integration Hell هو مصطلح عام يتجلى عندما يمر جميع أعضاء فريق التطوير بعملية تنفيذ التعليمات البرمجية الخاصة بهم في أوقات عشوائية مع عدم وجود طريقة لدمج أجزاء التعليمات البرمجية المختلفة في سلسلة واحدة من الكود. سيضطر فريق التطوير إلى قضاء عدة ساعات أو أيام في اختبار وتغيير الرمز للحصول على كل شيء للعمل.
من الناحية العملية ، يتم تطوير المكونات الأطول في عزلة ، وكلما تميزت الواجهات بين ما هو متوقع. عندما يتم دمج المكونات أخيراً في نهاية المشروع ، سيستغرق وقتاً أطول بكثير من تخصيصها ، وغالباً ما يؤدي إلى ضغوط المواعيد النهائية ، والتكامل الصعب. هذا العمل المؤلم التكامل في نهاية المشروع هو الجحيم مسمى.
التكامل المستمر ، الفكرة القائلة بأنه يجب على فريق التطوير استخدام أدوات محددة من أجل "الدمج المستمر" لأجزاء الشفرة التي يعملون عليها عدة مرات في اليوم ، بحيث يمكن للأدوات أن تتطابق مع "أجزاء" الكود المختلفة معًا لتتكامل أكثر بسلاسة. من ذي قبل.
تسمح مستودعات التعليمات البرمجية ، مثل Git (والواجهة المفتوحة المصدر التي نعرفها ونحبها بالكامل ، GitHub) لفرق التطوير بتنظيم جهودهم بحيث يمكن إنفاق المزيد من الوقت في الترميز ووقت أقل للقلق إذا كانت الأجزاء المختلفة من الشفرة سوف تتكامل.
[التكامل المستمر](https://guide.freecodecamp.org/agile/continuous-integration/) هو ترياق Agile لهذه المشكلة. لا يزال التكامل مؤلمًا ، لكن القيام بذلك على الأقل يوميًا يبقي على الواجهات بعيدة عن التباعد كثيرًا.
#### معلومات اكثر:
* [تجنب التكامل الجحيم](https://tobeagile.com/2017/03/08/avoiding-integration-hell/)
* [التكامل الجحيم](http://wiki.c2.com/?IntegrationHell)
* [أعلى 5 نصائح لتجنب "التكامل الجحيم" مع التكامل المستمر](https://www.apicasystems.com/blog/top-5-tips-avoid-integration-hell-continuous-integration/)
* [مقال D-Zone حول Integration Hell وكيف ساعد التكامل المستمر على جعله شيئًا من الماضي تقريبًا](https://dzone.com/articles/continuous-integration-how-0)

27
guide/arabic/agile/invest/index.md
View File

@ -1,27 +0,0 @@
---
title: INVEST
localeTitle: استثمار
---
## استثمار
**أنا** | **مستقل** ----- | -----
**ن** | **قابل للتفاوض** **V** | **ذو قيمة** **ه** | **جدير بالاحترام** **S** | **صغير** **تي** | **قابلة للاختبار**
عندما تقوم بتكرير وتحجيم "قصص المستخدم" في backlog ، يمكن أن يساعدك التذكير INVEST في تحديد ما إذا كانت جاهزة
* مستقل
* القصة متميزة بقدر الإمكان عن القصص الأخرى. تجنب "طابقين في واحد".
* قابل للتفاوض
* كجزء من المحادثة بين مالك المنتج وفريق التسليم أثناء الاستمالة ، يمكن مناقشة تفاصيل القصة وصقلها وتحسينها. يمكن تعديل معايير القبول بناءً على انحسار وتدفق احتياجات العملاء والقدرات التقنية.
* ذو قيمة
* هناك قيمة للعميل. الأموال المكتسبة ، والوقت المحفوظة ، والكفاءة المكتسبة ، والخسارة المتوقفة ، وما إلى ذلك من خلال تنفيذ القصة.
* جدير بالاحترام
* خلال الحياكة ، تناول الوصف والحديث للقصة ما يكفي من الأسئلة من فريق التسليم بحيث يمكنهم بثقة وقراءة مريحة للقصة.
* صغير
* يمكنك إكمال القصة ضمن التكرار الثابت.
* قابل للاختبار
* تتضمن القصة معايير القبول التي ستستخدمها للتأكيد على أن الشفرة تلبي احتياجات العميل.
#### معلومات اكثر:
[الكثير على جوجل](https://www.google.com/search?q=agile+invest+negotiable&ie=utf-8&oe=utf-8)

11
guide/arabic/agile/kano-analysis/index.md
View File

@ -1,11 +0,0 @@
---
title: Kano Analysis
localeTitle: تحليل كانو
---
## تحليل كانو
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/kano-analysis/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

38
guide/arabic/agile/lean-software-development/index.md
View File

@ -1,38 +0,0 @@
---
title: Lean Software Development
localeTitle: تطوير البرمجيات العجاف
---
## تطوير البرمجيات العجاف
### المقدمة
Lean Software Development هي عملية بناء البرمجيات مع التركيز على استخدام التقنيات التي تقلل من العمل الإضافي والجهد الضائع. يتم استعارة هذه التقنيات من حركة التصنيع اللين وتطبيقها على سياق تطوير البرمجيات.
### المفاهيم الرئيسية
هناك سبعة مبادئ في المنهجية والتي تشمل:
1. القضاء على النفايات
2. تضخيم التعلم
3. تقرر في وقت متأخر قدر الإمكان
4. تسليم في أسرع وقت ممكن
5. تمكين الفريق
6. بناء النزاهة في
7. شاهد الكل
### الاستعارات
يُنظر إلى عملية البرمجة على أنها خط تجميع ، حيث تسمى كل ميزة أو إصلاح أخطاء "طلب تغيير". يمكن عندئذٍ اعتبار خط التجميع هذا لـ "طلبات التغيير" على أنه "تيار قيمة" بحيث يكون الهدف هو تقليل الوقت الذي يقع فيه كل "طلب تغيير" على السطر قبل تسليمه.
تعتبر البرامج التي لم يتم تسليمها بعد "مخزونًا" نظرًا لأنها لم تقدم بعد قيمة للشركة أو العميل. يتضمن ذلك أي برنامج مكتمل جزئيًا. لذلك ، من أجل زيادة الإنتاجية إلى أقصى الحدود ، من المهم تقديم العديد من أجزاء العمل الصغيرة الكاملة.
من أجل تقليل "المخزون" ، من المهم فصل السيطرة إلى "العمال" الذين سيكونون مطوري البرمجيات ، لأنهم سيكونون أفضل تجهيزًا لإنشاء عمليات آلية "لإثبات الخطأ" في الأجزاء المختلفة من خط التجميع.
### المراجع
المصدر الأصلي للوثائق المكتوبة حول تقنيات Lean هو كتاب Lean Software Development ، مجموعة أدوات Agile Tool من تأليف Mary و Tom Poppendieck.
الكتب الإضافية التي كتبها المؤلف (المؤلفون) تشمل:
* تنفيذ تطوير البرمجيات العجاف: من المفهوم إلى النقد من قبل ماري Poppendieck
* قيادة تطوير البرمجيات العجاف: النتائج ليست نقطة من قبل ماري Poppendieck

11
guide/arabic/agile/meta-scrum/index.md
View File

@ -1,11 +0,0 @@
---
title: Meta Scrum
localeTitle: سكروم ميتا
---
## ميتا سكروم
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/meta-scrum/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

25
guide/arabic/agile/minimum-marketable-features/index.md
View File

@ -1,25 +0,0 @@
---
title: Minimum Marketable Features
localeTitle: الحد الأدنى من الميزات القابلة للتسويق
---
## الحد الأدنى من الميزات القابلة للتسويق
الميزة القابلة للتسويق (MMF) هي ميزة قائمة بذاتها يمكن تطويرها بسرعة وتعطي قيمة كبيرة للمستخدم.
**من المهم ملاحظة ما يلي:** ميزة الحد الأدنى للتسويق ليست هي نفس الحد الأدنى من المنتج القابل للتطبيق (MVP). إنها مفاهيم مختلفة. ومع ذلك ، كلاهما ضروري لدعم فكرة أن المطورين يجب أن نسعى للحصول على الحد الأدنى من الوظائف من أجل تحقيق أي نتيجة معينة.
تقسيم MMF إلى مكوناته الأساسية:
**الحد الأدنى** - أصغر مجموعة من الوظائف. هذا أمر ضروري للحصول على أي ميزة للسوق بسرعة
**قابل للتسويق** - بيع المستخدم النهائي أو المؤسسة التي تحتوي على قيمة كبيرة
**ميزة** - القيمة percieved من قبل المستخدم النهائي. ماذا يعطيني؟ إعتراف بعلامة تجارية؟ المزيد من الإيرادات؟ مساعدة في خفض التكاليف؟ هل يعطيني ميزة تنافسية؟
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:
### مصادر
1. [https://www.agilealliance.org/glossary/mmf/ تم الوصول إليه: 25 من تشرين الأول 2017](https://www.agilealliance.org/glossary/mmf/) 2. [https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential تاريخ الوصول: 25 أكتوبر ، 2017](https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential)

15
guide/arabic/agile/minimum-viable-product/index.md
View File

@ -1,15 +0,0 @@
---
title: Minimum Viable Product
localeTitle: الحد الأدنى المنتج قابلة للحياة
---
## الحد الأدنى المنتج قابلة للحياة
تكمن الفكرة في إنشاء مجموعة بسيطة من الميزات بسرعة كافية لنشر المنتج واختبار الافتراضات الأساسية حول تفاعلات العملاء مع المنتج.
#### يحتوي منتج الحد الأدنى القابل للتطبيق على ثلاث خصائص رئيسية:
* لديها قيمة كافية بحيث يكون الناس على استعداد لاستخدامها أو شرائها في البداية.
* إنه يوضح فائدة مستقبلية كافية للاحتفاظ بالاعتماد الأوائل.
* يوفر حلقة تغذية مرتدة لتوجيه التطوير المستقبلي.
تعلم المزيد عن MVP: [ما هو mvp؟](https://youtu.be/MHJn_SubN4E)

50
guide/arabic/agile/moscow/index.md
View File

@ -1,50 +0,0 @@
---
title: Moscow
localeTitle: موسكو
---
## موسكو
## طريقة MoSCoW
أحد معاني هذه الكلمة هو طريقة MoSCoW - وهي تقنية تحديد الأولويات المستخدمة في الإدارة ، وتحليل الأعمال ، وإدارة المشاريع ، وتطوير البرمجيات للوصول إلى فهم مشترك مع أصحاب المصلحة حول الأهمية التي يضعونها في تقديم كل متطلبات - والمعروف أيضًا باسم تحديد أولويات MoSCoW أو تحليل MoSCoW.
## تحديد أولويات متطلبات MoSCoW
جميع المتطلبات مهمة ، ولكن يتم تحديد أولوياتها لتقديم أكبر فوائد الأعمال وأقربها في وقت مبكر. سيحاول المطورون في البداية تقديم كل ما يجب أن يكون ، ويجب أن يكون لديه ، ويمكن أن يكون لديه متطلبات ، لكن متطلبات Should و Could ستكون أول من يتم إزالته إذا كان الجدول الزمني للتسليم يبدو مهددًا.
إن لمعنى اللغة الإنجليزية البسيط لفئات الأولويات قيمة في حث العملاء على فهم تأثير تحديد الأولوية بشكل أفضل ، مقارنة بالبدائل مثل High، Medium و Low.
يتم فهم الفئات عادة على النحو التالي:
## يجب ان يملك
`Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT.
`
## يجب ان
`Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
`
## قد يكون له
`Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
`
## لن يكون
`Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox.
`
تعد MoSCoW طريقة حبيبية خشنة لتحديد أولويات (تصنيف) عناصر تراكم المنتجات (أو المتطلبات ، حالات الاستخدام ، قصص المستخدمين ... حسب المنهجية المستخدمة). وكثيرا ما يستخدم MoSCoW مع timeboxing ، حيث يتم تحديد موعد نهائي بحيث يكون التركيز على أهم المتطلبات. مصطلح MoSCoW نفسه هو اختصار مستمد من الحرف الأول من كل فئة من فئات الأربع (يجب أن يكون ، يجب أن يكون ، قد يكون ، ولن يكون):
* **يجب أن يكون** : حاسمة إلى timebox التسليم الحالي من أجل أن يكون ناجحا. وهو عادة جزء من MVP (منتج قابل للتطبيق بحد أدنى).
* **يجب أن يكون** : مهم ولكنه غير ضروري للتسليم في timebox التسليم الحالي.
* **يمكن أن يكون** : من المرغوب فيه ولكن ليس من الضروري ، وهو تحسن.
* **لن يكون لديك** : العناصر الأقل حرجًا أو أقل الاسترداد أو غير مناسبة في الوقت الحالي.
من خلال تحديد الأولويات بهذه الطريقة ، يمكن الوصول إلى تعريف مشترك للمشروع وتعيين توقعات أصحاب المصلحة وفقًا لذلك. لاحظ أن MoSCoW هو قليل التراخي حول كيفية التمييز بين فئة عنصر وعندما يتم القيام بشيء ما ، إن لم يكن في هذا timebox.
#### معلومات اكثر:
[ويكيبيديا](https://en.wikipedia.org/wiki/MoSCoW_method)

26
guide/arabic/agile/nonfunctional-requirements/index.md
View File

@ -1,26 +0,0 @@
---
title: Nonfunctional Requirements
localeTitle: متطلبات غير مجدية
---
## متطلبات غير مجدية
المتطلبات غير الوظيفية (NFR) هو مطلب يحدد المعايير التي يمكن استخدامها للحكم على تشغيل النظام ، بدلاً من السلوكيات المحددة (متطلب وظيفي). غالبًا ما تُسمى المتطلبات غير الوظيفية "سمات الجودة" أو "القيود" أو "المتطلبات غير السلوكية".
بشكل غير رسمي ، يطلق عليها أحيانًا "مهارات" ، من سمات مثل الاستقرار وسهولة الحمل. يمكن تقسيم NFRs إلى فئتين رئيسيتين:
* **صفات التنفيذ** ، مثل السلامة والأمان وسهولة الاستخدام ، والتي يمكن ملاحظتها أثناء التشغيل (وقت التشغيل).
* **خصائص التطور** ، مثل قابلية الاختبار ، والقابلية للصيانة ، والقابلية للتوسع والقابلية للتطوير ، والتي تتجسد في البنية الثابتة للنظام
عادة يمكنك تحسين المتطلبات غير الوظيفية في مجموعة من المتطلبات الوظيفية كطريقة للتفصيل والسماح للاختبار (الجزئي) والتحقق من الصحة.
### أمثلة:
* يجب أن تطبع الطابعة 5 ثوان بعد الضغط على الزر
* يجب كتابة الكود في جافا
* يجب أن تكون واجهة المستخدم قابلة للملاحة بسهولة
#### معلومات اكثر:
* [مقالة ويكيبيديا](https://en.wikipedia.org/wiki/Non-functional_requirement)
* [ReQtest](http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/) يشرح الفرق بين المتطلبات الوظيفية وغير الوظيفية
* [تحجيم رشيق](http://www.scaledagileframework.com/nonfunctional-requirements/) يعمل من خلال عملية من العثور على اختبار متطلبات غير وظيفية

12
guide/arabic/agile/osmotic-communications/index.md
View File

@ -1,12 +0,0 @@
---
title: Osmotic Communications
localeTitle: Osmotic Communications
---
## Osmotic Communications
**تعد شركة Osmotic Communications** واحدة من العوامل الهامة لمشروع رشيق ناجح.
في مشروع رشيق ، عادة ما يتواجد أعضاء الفريق في نفس المكان ، وسوف تتدفق أي مناقشات بين بعض أعضاء الفريق إلى أعضاء الفريق الآخرين. يمكنهم بعد ذلك التقاط المعلومات ذات الصلة والانضمام للمناقشة عند الضرورة.
#### معلومات اكثر:

12
guide/arabic/agile/pair-programming/index.md
View File

@ -1,12 +0,0 @@
---
title: Pair Programming
localeTitle: برمجة الزوج
---
## برمجة الزوج
يوصي برنامج Extreme Programming (XP) بكتابة كل كود الإنتاج من قبل اثنين من المبرمجين يعملان في نفس الوقت على نفس الكمبيوتر ، مع تشغيل لوحة المفاتيح. لقد أثبتت العديد من الدراسات الأكاديمية أن برمجة الأزواج تنتج في عدد أقل من الأخطاء والمزيد من البرامج القابلة للإصلاح. يمكن أن تساعد برمجة الزوج أيضًا في نشر المعرفة داخل الفريق ، والمساهمة في [عامل](http://deviq.com/bus-factor/) أكبر [للحافلات](http://deviq.com/bus-factor/) والمساعدة في الترويج [لملكية كود الجماعية](http://deviq.com/collective-code-ownership/) .
#### معلومات اكثر:
* [أساسيات البرمجة الزوجية (دورة تدريبية)](http://bit.ly/PS-PairProgramming)
* [Agile Software Programming Best Practices](https://www.versionone.com/agile-101/agile-software-programming-best-practices/pair-programming/)

11
guide/arabic/agile/parallel-development/index.md
View File

@ -1,11 +0,0 @@
---
title: Parallel Development
localeTitle: التنمية الموازية
---
## التنمية الموازية
يقف التطوير الموازي لعملية التطوير منفصلة إلى فروع متعددة ، لتوفير منتج متعدد الاستخدامات مع إصدارات مستقرة وميزات جديدة. في عملية تطوير برامج مباشرة أكثر شيوعًا ، لديك فرع واحد فقط مع إصلاحات وتحسينات للأخطاء ، جنبًا إلى جنب مع الميزات الجديدة. في تطوير موازية يمكن أن تتعايش فروع متعددة.
عادة ما يحتوي التطوير المتوازي على فرع رئيسي "رئيسي" وهو الأكثر استقرارًا ويحتوي على إصلاحات مهمة للرمز الحالي. من الفرع الرئيسي ، يتم إنشاء المزيد من الفروع لإضافة "مسارات" جديدة إلى الشفرة الحالية. توفر هذه الفروع ميزات جديدة ، ولكنها لا تتضمن إصلاحات ، يتم تطبيقها في الوقت الحالي من الفرع الرئيسي. يعرف العملاء عن هذه الإصدارات ولديهم معدات خاصة ، أو آلات اختبار ليتمكنوا من اختبار الميزات الجديدة. عندما يتم تمرير اختبارات ضمان الجودة ، يمكن دمج الفرع الجانبي مع الفرع الرئيسي لتقديم ميزات جديدة إلى نسخة الإصدار.
#### معلومات اكثر:

19
guide/arabic/agile/pirate-metrics/index.md
View File

@ -1,19 +0,0 @@
---
title: Pirate Metrics
localeTitle: قياسات القراصنة
---
## قياسات القراصنة
حدد Dave McClure خمس فئات للمقاييس عالية الأهمية لنجاح الشركات الناشئة: الاستحواذ ، التنشيط ، الاحتفاظ ، الإيرادات ، الإحالة.
صاغ مصطلح "قياسات القراصنة" من اختصار لهذه الفئات الخمس من المقاييس (AARRR).
في كتابهم Lean Analytics ، يفسر Croll و Yoskovitz هذه المقاييس بصريًا باعتبارها مسار تحويل: ![ليين تحليلات الشكل 5.1](https://github.com/yunChigewan/storage/blob/master/figure_5_1.jpg?raw=true) Lean Analytics ، 2013
ومع تفسيرات أكثر وضوحًا كجدول: ![لين تحليلات الجدول 5.1](https://github.com/yunChigewan/storage/blob/master/table_5_1.jpg?raw=true) Lean Analytics ، 2013
#### معلومات اكثر:
* القراصنة القياسات الأصلية عرض الشرائح (McClure) https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
* موقع Lean Analytics Book http://leananalyticsbook.com/
* فكرة لديها دليل جيد حقا في القياسات القياسات (بما في ذلك تدابير فريق) على [موقعه](http://usenotion.com/aarrrt/) على [الانترنت](http://usenotion.com/aarrrt/)

39
guide/arabic/agile/planning-poker/index.md
View File

@ -1,39 +0,0 @@
---
title: Planning Poker
localeTitle: تخطيط لعبة البوكر
---
## تخطيط لعبة البوكر
### المقدمة
التخطيط للبوكر هو تقنية تقدير وتخطيط في نموذج تطوير Agile. يتم استخدامه لتقدير جهود التطوير المطلوبة [لقصة المستخدم](../user-stories/index.md) أو ميزة.
### معالجة
يتم التخطيط لعبة البوكر لقصة مستخدم واحد في وقت واحد.
يحمل كل مقدّر مجموعة متطابقة من بطاقات البوكر التي تتكون من بطاقات ذات قيم مختلفة. عادةً ما تكون قيم البطاقة من تسلسل فيبوناتشي. يمكن أن تكون الوحدة المستخدمة للقيم عدد الأيام ، أو نقاط القصة ، أو أي نوع آخر من وحدات التقدير التي وافق عليها الفريق.
يشرح مالك المنتج (PO) أو صاحب المصلحة القصة المراد تقديرها.
يناقش الفريق القصة ، ويسأل أي أسئلة توضيحية قد تكون لديهم. يساعد هذا الفريق في الحصول على فهم أفضل _لما_ يريده أمر الشراء.
في نهاية المناقشة ، يختار كل شخص أولاً بطاقة (تمثل تقديره للقصة) دون عرضها على الآخرين. ثم يكشفون عن أوراقهم في نفس الوقت.
إذا كانت جميع البطاقات لها نفس القيمة ، تصبح القيمة هي التقدير للقصة. إذا كانت هناك اختلافات ، يناقش الفريق أسباب القيم التي اختاروها. من الأهمية بمكان أن يقدم أعضاء الفريق الذين قدموا التقديرات الأدنى والأعلى تبريرات لتقديراتهم.
بعد هذه المناقشة ، تتكرر عملية اختيار بطاقة خاصة ثم الكشف عنها في نفس الوقت. يتم ذلك حتى يكون هناك توافق في الآراء حول التقدير.
لأن التخطيط للبوكر هو أداة لتخفيف تقدير الخبير _المشترك_ ، فإنه يؤدي إلى فهم مشترك أفضل وربما تحسين طلب الميزة. إنها ذات قيمة عالية حتى عندما يعمل الفريق في وضع No-Estimates.
يجب على المشرف محاولة تجنب التحيز في التأكيد.
الأشياء الجديرة بالذكر:
* التقديرات لا يمكن مقارنتها بين الفرق ، حيث أن كل فريق له مجاله الخاص.
* يجب أن تتضمن التقديرات كل ما يجب القيام به من أجل القيام بجزء من العمل: التصميم ، الترميز ، الاختبار ، الاتصال ، مراجعة الشفرات (+ جميع المخاطر المحتملة)
* إن قيمة استخدام لعبة البوكر التخطيطية هي في المناقشات الناتجة ، لأنها تكشف عن وجهات نظر مختلفة حول التنفيذ المحتمل
### معلومات اكثر:
* تخطيط فيديو البوكر: [يوتيوب](https://www.youtube.com/watch?v=MrIZMuvjTws)

52
guide/arabic/agile/product-management/index.md
View File

@ -1,52 +0,0 @@
---
title: Product Management
localeTitle: ادارة المنتج
---
## ادارة المنتج
إدارة المنتجات هي وظيفة تنظيمية تتحمل المسؤولية عن دورة الحياة الكاملة للمنتجات التي يتم بيعها. كوظيفة عمل ، إدارة المنتجات ، تخضع للمساءلة عن إنشاء قيمة العميل ومزايا قابلة للقياس للأعمال.
هناك بعض المسؤوليات الأساسية المشتركة لمعظم أدوار إدارة المنتج داخل شركات المؤسسة القائمة والشركات الناشئة. غالباً ما تكون إدارة المنتج مسؤولة عن فهم متطلبات العملاء وتحديدها وترتيبها حسب الأولوية ، والعمل مع الفريق الهندسي لبناء هذه المتطلبات. غالبًا ما يُعتبر وضع الإستراتيجية وتحديد خريطة الطريق عملاً واردًا ، وغالبًا ما يُعتبر عرض المنتج إلى السوق "خارجيًا".
من المهم أن نفهم الاختلافات بين إدارة المنتجات الواردة والصادرة ، لأن مدير منتج كبير لديه مجموعة متنوعة من المهارات للقيام بكل من جيد.
الفرق بين إدارة المنتج وإدارة المشاريع هو ، المقياس ودورة الحياة. يقوم مديرو المشروعات بالتأكد من تسليم العديد من المنتجات / الخدمات / المشاريع إلى أحد العملاء ، بينما يتجه مديرو المنتجات إلى ما هو أبعد من التطوير ويعملون من أجل الوصول إلى فترة طويلة وتشغيل منتج / خدمة.
في تطوير اللعبة ، يمكننا رؤية التحول الواضح من المشاريع إلى المنتجات نظرًا للألعاب التي تحتوي على خطط إطلاق ونشر أكثر تفصيلاً واستراتيجيات لتحقيق الدخل.
### إدارة المنتجات الواردة
تشمل إدارة المنتجات الداخلية جمع أبحاث العملاء ، والذكاء التنافسي ، واتجاهات الصناعة بالإضافة إلى وضع الإستراتيجية وإدارة خارطة طريق المنتج.
استراتيجية المنتج وتعريفه (الوارد)
* الاستراتيجية والرؤية
* مقابلات العملاء
* تحديد الميزات والمتطلبات
* بناء خرائط الطريق
* إدارة الإفراج
* الذهاب إلى الموارد للهندسة
* تدريب المبيعات والدعم
### إدارة المنتجات الصادرة
تشمل إدارة المنتجات الخارجية مسؤوليات تسويق المنتجات مثل: الرسائل والعلامات التجارية ، وتواصل العملاء ، وإطلاق منتجات جديدة ، والإعلانات ، والعلاقات العامة ، والأحداث. اعتمادًا على التنظيم ، يمكن تنفيذ هذه الأدوار من قبل الشخص نفسه أو شخصين مختلفين أو مجموعات مختلفة تعمل معًا بشكل وثيق.
تسويق المنتجات والذهاب إلى السوق (الصادرة)
* التمايز التنافسية
* تحديد المواقع والرسائل
* التسمية والعلامات التجارية
* الاتصالات العملاء
* إطلاق المنتج
* علاقات الصحافة والمحللين
### مدير الإنتاج
تستمر إدارة المنتج في التوسع كمهنة. يزداد الطلب على مديري المنتجات المؤهلين على كل المستويات. هناك مجموعة متنوعة من الأدوار والمسؤوليات حسب مستوى الخبرة. تتراوح الفرص من مدير منتج منتسب إلى CPO.
كان معظم مدراء المنتجات في أدوار مختلفة في وقت مبكر من حياتهم المهنية. في كثير من الأحيان ينمو مهندسو البرمجيات أو مهندسو المبيعات أو مستشار الخدمات المهنية في دور مدير المنتج. ولكن في بعض الشركات (مثل Google و Facebook و…) ، يتم تعيين مدراء منتجات صغار مباشرة خارج المدرسة ، مدعومين ببرامج مهنية لتعليمهم في العمل.
#### معلومات اكثر:
صفحة ويكيبيديا: https://en.wikipedia.org/wiki/Product\_management

33
guide/arabic/agile/product-owners/index.md
View File

@ -1,33 +0,0 @@
---
title: Product Owners
localeTitle: مالكو المنتج
---
## مالكو المنتج
يقود مالكو المنتج رؤية المنتج والتخطيط للإصدار. فهي مسؤولة عن تحديد الميزات وتاريخ الإصدار والمحتوى الذي يصنع منتجًا قابلًا للتنزيل. الهدف من مالك المنتج هو بناء الشيء الصحيح بسرعة وبشكل صحيح.
على المستوى العالي ، يكون مالك المنتج مسؤولاً عن ما يلي:
* مالك رؤية المنتج
* يؤدي الافراج عن التخطيط
* يحدد الميزات ومحتوى الإصدار
* يدير فهم الفريق للإصدار
* يخلق ويرعى تراكم المنتج
* يعطي الأولوية لأعلى تراكم المنتج
* فريق الأدلة من خلال دورة الإصدار
* يتخذ قرارات المقايضة
* يقبل أو يرفض العمل
ينشئ مالك المنتج تراكمًا للعناصر التي يعتقد أنها ستجعل منتجًا جيدًا. تستند هذه المعرفة على فهمهم للسوق ، واختبار المستخدم ، وإسقاط السوق. يعدّل مالكو المنتج الأهداف طويلة الأجل للمنتج بناءً على التعليقات التي يتلقونها من المستخدمين وأصحاب المصلحة. كما أنها بمثابة نقطة الاتصال مع أصحاب المصلحة وإدارة نطاق وتوقعات.
بمجرد أن يتلقى مالك المنتج تعليقات من مختلف أصحاب المصلحة ، يقومون بعد ذلك بتنقيح الأعمال المتأخرة لإضافة أكبر قدر ممكن من التفاصيل من أجل إنشاء منتج قابل للتطبيق (MVP) لهذا الإصدار.
ثم يعطي مالك المنتج الأولوية لحملة العمل للتأكد من أن القصص المكتملة تتناول كل من قيمة العمل وأهداف المستخدمين. كذلك ، إذا كانت هناك مخاطر مرتبطة ببعض القصص ، يضع مالك المنتج تلك الموجودة في الجزء العلوي من المتأخرات حتى يتم التعامل مع المخاطر في وقت مبكر.
من خلال العمل مع الفريق و Scrum Master ، يحضر مالك المنتج اجتماعات تخطيط السباقات من أجل إعداد قصص مدهشة في السباق. خلال فترة الركض ، يضمن مالك المنتج أن يقوم الفريق بإكمال العمل وفقًا لتعريف Done (DoD) ، والإجابة على أية أسئلة قد تطرأ ، وتحديث أصحاب المصلحة.
عند اكتمال السرعة ، يشارك مالك المنتج في مراجعة Sprint مع أصحاب المصلحة الآخرين. للتأكد من أن كل قصة تتوافق مع وزارة الدفاع ، فإن مالك المنتج يستعد لسباق السرعة التالي من خلال جمع التعليقات وتحديد أولويات العمل بناءً على ما تم إكماله.
### معلومات اكثر:
* ملكية المنتج Agile في فيديو Nutshell: [YouTube](https://www.youtube.com/watch?v=502ILHjX9EE)

14
guide/arabic/agile/rapid-application-development/index.md
View File

@ -1,14 +0,0 @@
---
title: Rapid Application Development
localeTitle: التطوير السريع للتطبيق
---
## التطوير السريع للتطبيق
تم تطوير تطوير التطبيقات السريعة (RAD) كرد فعل على مشاكل منهجيات تطوير البرمجيات التقليدية ، وخاصة مشاكل فترات التطوير الطويلة. كما يتناول المشاكل المرتبطة بتغيير المتطلبات خلال عملية التطوير.
المبادئ الرئيسية لل RAD هي كما يلي: 1) تنمية تدريجية. هذه هي الوسيلة الرئيسية التي يعالج بها RAD المتطلبات المتغيرة. ستظهر بعض المتطلبات فقط عندما يرى المستخدمون النظام قيد الاستخدام ويختبرونه. لا ينظر إلى المتطلبات على أنها كاملة - فهي تتطور بمرور الوقت بسبب الظروف المتغيرة. تبدأ عملية RAD بقائمة عالية المستوى وغير محددة من المتطلبات التي يتم تنقيحها أثناء عملية التطوير. 2) Timeboxing. مع timeboxing ، يتم تقسيم النظام إلى عدد من المكونات أو timeboxes التي يتم تطويرها بشكل منفصل. يتم تطوير المتطلبات الأكثر أهمية في timebox الأول. يتم تسليم الميزات بسرعة وبشكل متكرر. 3) مبدأ باريتو. يُعرف أيضًا باسم قاعدة 80/20 ، وهذا يعني أنه يمكن تسليم حوالي 80٪ من وظائف النظام بحوالي 20٪ من إجمالي الجهد المطلوب. لذلك ، فإن آخر (وأكثرها تعقيدًا) 20٪ من المتطلبات تتطلب أقصى مجهود ووقت للتسليم. لذا ، يجب أن تختار أكثر من 80٪ لتسليمها قدر الإمكان في إطار timeboxes القليلة الأولى. أما الباقي ، إذا ثبت أنه ضروري ، فيمكن تسليمه في timeboxes لاحقة. 4) قواعد MoSCoW. MoSCoW هي طريقة تستخدم لتحديد أولويات بنود العمل في تطوير البرمجيات. يتم تصنيف العناصر كما يجب ، يجب أن يكون لديك ، يمكن أن يكون أو يريد أن يكون. يجب أن تكون العناصر هي تلك التي يجب تضمينها في منتج ليتم قبولها في الإصدار ، مع التصنيفات الأخرى في الأولوية التنازلية. 5) ورش عمل JAD. تطوير التطبيقات المشتركة (JAD) هو عبارة عن اجتماع يتم تسهيله حيث يتم تنفيذ تجميع المتطلبات ، وخاصة إجراء مقابلات مع مستخدمي النظام الذي سيتم تطويره. ﻋﺎدة ﻣﺎ ﺗﺟرى ورﺷﺔ ﻋﻣل JAD ﻓﻲ وﻗت ﻣﺑﮐر ﻓﻲ ﻋﻣﻟﯾﺔ اﻟﺗﻧﻣﯾﺔ ، ﻋﻟﯽ اﻟرﻏم ﻣن أﻧﮫ ﯾﻣﮐن ﺗﻧظﯾم اﺟﺗﻣﺎﻋﺎت إﺿﺎﻓﯾﺔ إذا ﻟزم اﻷﻣر ﻓﻲ وﻗت ﻻﺣق ﻣن اﻟﻌﻣﻟﯾﺔ. 6) النماذج. يساعد إنشاء نموذج أولي على إنشاء متطلبات المستخدم وتوضيحها ، وفي بعض الحالات يتطور ليصبح النظام نفسه. 7) الراعي والبطل. الراعي التنفيذي هو شخص داخل المنظمة يريد النظام ويلتزم بتحقيقه ومستعد لتمويله. البطل هو شخص ما ، عادة ما يكون في مستوى أدنى من الأقدمية من مسؤول تنفيذي ، ملتزم بالمشروع ومستعد لدفعه إلى الأمام حتى الانتهاء. 8) أدوات. عادة ما يعتمد RAD أدوات مجموعة كوسيلة لتسريع عملية التطوير وتحسين الإنتاجية. تتوفر أدوات للتحكم في التغيير وإدارة التكوين وإعادة استخدام الكود.
#### معلومات اكثر:
* https://en.wikipedia.org/wiki/ تطوير _تطبيق_ رابيد - مقالة ويكيبيديا على RAD
* https://www.tutorialspoint.com/sdlc/sdlc _rad_ model.htm - البرنامج التعليمي TutorialsPoint على RAD

11
guide/arabic/agile/rational-unified-process/index.md
View File

@ -1,11 +0,0 @@
---
title: Rational Unified Process
localeTitle: عملية موحدة عقلانية
---
## عملية موحدة عقلانية
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/rational-unified-process/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

11
guide/arabic/agile/release-planning/index.md
View File

@ -1,11 +0,0 @@
---
title: Release Planning
localeTitle: تخطيط الإصدار
---
## تخطيط الإصدار
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/agile/release-planning/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

19
guide/arabic/agile/release-trains/index.md
View File

@ -1,19 +0,0 @@
---
title: Release Trains
localeTitle: الافراج عن القطارات
---
## الافراج عن القطارات
يعد قطار الإصدار (المعروف أيضًا باسم قطار الإصدار السريع أو ART) فريقًا طويل العمر من فرق Agile ، التي تقوم ، جنبًا إلى جنب مع أصحاب المصلحة الآخرين ، بتطوير وتقديم الحلول بشكل متزايد ، وذلك باستخدام سلسلة من التكرارات ذات الطول الثابت ضمن زيادة البرنامج ( PI) timebox. يقوم ART بمحاذاة الفرق إلى مهمة تجارية وتقنية مشتركة.
## تفاصيل
ART هي متعددة الوظائف ولديها جميع القدرات - البرامج والأجهزة والبرامج الثابتة وغيرها - اللازمة لتحديد وظائف النظام الجديدة وتنفيذها واختبارها ونشرها. تعمل ART بهدف تحقيق تدفق مستمر للقيمة.
تتضمن ART أدوات التعريف التي تعمل على تحديد الميزات والمكونات وإنشائها واختبارها. لدى فرق SAFe خيارًا من الممارسات الرشيقة ، التي تعتمد أساسًا على Scrum و XP و Kanban. تشمل ممارسات جودة البرمجيات التكامل المستمر والاختبار أولاً وإعادة بيع ديون والعمل الزوجي والملكية الجماعية. يتم دعم جودة الأجهزة من خلال الاستكشافات المبكرة الاستكشافية ، والتكامل المتكرر على مستوى النظام ، والتحقق من التصميم ، والنمذجة ، والتصميم المعتمد على المجموعة.
الهندسة المعمارية رشيقة تدعم جودة البرامج والأجهزة. يحتوي كل فريق Agile على ما بين 5 إلى 9 من المساهمين الفرديين المتفانين ، حيث يقومون بتغطية جميع الأدوار اللازمة لبناء زيادة جودة للقيمة للتكرار. يمكن للفرق تقديم البرامج والأجهزة وأي مجموعة. وبالطبع ، فإن فرق Agile ضمن ART هي نفسها وظيفية.
#### معلومات اكثر:
[رشيق التدريج](http://www.scaledagileframework.com/agile-release-train/) .

43
guide/arabic/agile/retrospectives/index.md
View File

@ -1,43 +0,0 @@
---
title: Retrospectives
localeTitle: استعادية
---
## استعادية
يمكن أن يكون Sprint Retrospective أكثر فائدة وأهمية لحفلات سكروم.
يعتبر مفهوم _"الفحص والتكيف"_ أمرًا ضروريًا لإنشاء فريق ناجح ومزدهر.
جدول الأعمال القياسي لأثر رجعي هو:
* ماذا سنفعل؟
* ماذا نتوقف عن فعله؟
* ماذا نبدأ في فعله؟
* من نريد أن نقول شكرا لك؟ (ليس من الضروري ولكن الممارسة الجيدة)
ومن خلال هذه المناقشة ، ينشئ الفريق قائمة من السلوكيات التي يعملون عليها ، بشكل جماعي ، مع مرور الوقت.
عند الالتفات إلى عناصر العمل ، تأكد من التركيز على 1 - 3. من الأفضل أن تقوم بالزوجين ، بدلاً من الإلتزام بالمزيد وعدم القيام به. إذا كان من الصعب وضع إجراءات ، فجرّب إجراء التجارب: اكتب ما ستفعله وما تريد تحقيقه من خلال ذلك. في الاختيار الرجعية التالية ما إذا كنت قد حققت ما كنت قد خططت. إذا لم يحدث ذلك - يمكنك التعلم من التجربة وتجربة شيء آخر.
نهج جيد لمعرفة المواضيع التي ينبغي مناقشتها هي _"مناقشة وذكر"_ . وهو يتألف من لوحة تحتوي على عدد كبير من الأعمدة كأشخاص في الفريق (يمكنك استخدام شيء مثل Trello أو مجرد لوحة بيضاء عادية) واثنين آخرين للأشياء "للمناقشة" وتلك التي سيتم "ذكرها". كل شخص لديه 10 دقائق لملء عمودهم بأشياء من العدو الأخير الذي يريدون إبرازه (يتم تمثيلهم بالبطاقات أو ما بعدها). بعد ذلك ، يشرح كل عضو في الفريق كل عنصر من البنود الخاصة به. وأخيرًا ، يختار كل عضو في الفريق الموضوعات التي يعتقدون أنه يجب ذكرها أو مناقشتها ، وذلك عن طريق تحريك البطاقة / نشرها إلى العمود على التوالي. ثم يقرر الفريق الموضوعات التي ينبغي مناقشتها والتحدث عنها لمدة 10 دقائق.
دعوة فريق سكروم فقط لأثر رجعي. (فريق التسليم ، مالك المنتج ، سكروم ماستر). تثبيط المديرين وأصحاب المصلحة وشركاء الأعمال ، وما إلى ذلك. فهي تشتيت الانتباه ويمكن أن تعوق الشعور بالانفتاح الذي يحتاجه الفريق.
عند إجراء بحث استعادي ، تأكد من أنه في أول 5 إلى 10 دقائق ، يقول كل شخص على الأقل بضع كلمات. عندما يتحدث أعضاء الفريق في بداية الاجتماع ، فمن الأرجح أنهم يساهمون خلال الاجتماع بأكمله.
من المفيد أن يظل الفريق منتجا خلال فترة استعادة الأحداث. طريقة بسيطة لإبقاء الناس في حالة مزاجية إيجابية هي التركيز على ما هو في سيطرة الفريق.
* لفريق مشترك ، وبطاقات الفهرسة وعمل ما بعدها كبيرة لهذه العملية.
* بالنسبة للفرق الموزعة ، هناك مجموعة متنوعة من الأدوات والتطبيقات عبر الإنترنت لتسهيل المناقشة
* https://www.senseitool.com/home
* http://www.leancoffeetable.com/
يجب ذكر عناصر الإجراءات على لوحة لجعل تتبع التقدم مرئيًا وأكثر تمييزًا. يجب أن تبدأ كل مراجعة استرجاعية جديدة بمراجعة حالة بنود العمل التي تم اتخاذ قرار بشأنها خلال عملية الاستعادة _السابقة_ .
#### معلومات اكثر:
* الإلهام لإعداد دراسة استعادية:
* https://plans-for-retrospectives.com/en/
* http://www.funretrospectives.com/
* كيفية تشغيل التجارب مع تدفق الفشار:
* https://www.slideshare.net/cperrone/popcornflow-continuous-evolution-through-ultrarapid-experimentation

39
guide/arabic/agile/safe/index.md
View File

@ -1,39 +0,0 @@
---
title: SAFe
localeTitle: آمنة
---
## آمنة
SAFe لتقف على "إطار رشيق مقياس" ، وهو إطار تطوير البرمجيات رشيقة التي تم تصميمها لتطوير رشيقة واسعة النطاق التي تنطوي على العديد من الفرق.
الموقع الرئيسي ( [http://www.scaledagileframework.com/](http://www.scaledagileframework.com/) ) هو قاعدة معارف متاحة على الإنترنت متاحة مجاناً عن تطبيق SAFe.
## مبادئ
هناك تسعة مبادئ أساسية للسفينة
1. **اتخاذ وجهة نظر اقتصادية** - تقييم التكاليف الاقتصادية للقرارات والتطورات والمخاطر
2. **تطبيق أنظمة التفكير** - عمليات التطوير هي تفاعلات بين الأنظمة المستخدمة من قبل العمال وبالتالي تحتاج إلى عرض التقدم في التفكير المنظوماتي
3. **افترض تقلب الحفاظ على الخيارات** - تتغير المتطلبات ، وتكون مرنة ، وتستخدم البيانات التجريبية لتضييق نطاق التركيز
4. **بناء تدريجيًا مع دورات تعلم سريعة ومتكاملة** - **التصاميم** السريعة والمتزايدة تسمح بردود الفعل السريعة لتغيير المشروع إذا لزم الأمر
5. **المعالم الأساسية في التقييم الموضوعي لنظم العمل** - يوفر التقييم الموضوعي معلومات هامة مثل البيانات المالية والحوكمة كردود فعل
6. **تصور وتخفيض WIP ، والحد من أحجام الدُفعات ، وإدارة أطوال قائمة الانتظار** - قم بذلك لتحقيق التدفق المستمر للتحرك بسرعة وتصور التقدم ؛ WIP = العمل قيد التقدم
7. **تطبيق الإيقاع والتزامن مع التخطيط عبر النطاقات** - الإيقاع هو إعداد التواريخ عند حدوث أحداث معينة (على سبيل المثال إطلاق أسبوعيًا) والتزامن يجعل كل شخص لديه نفس الأهداف في الحسبان
8. **أطلق العنان للدوافع الجوهرية للعاملين في مجال المعرفة** - فالناس يعملون بشكل أفضل عندما تستخدمون دوافعهم الشخصية
9. **لا مركزية صنع القرار** - يتيح اتخاذ إجراء أسرع ، وهو ما قد لا يكون الحل الأفضل ، ولكنه يتيح اتصال أسرع بين الفرق ؛ قد يكون صنع القرار المركزي ضروريًا لاتخاذ قرارات أكثر استراتيجية أو عالمية
## تكوينات
هناك أربعة أنواع من SAFe ، تختلف في تعقيد احتياجات مشروعك:
1. السلامة الأساسية
2. محفظة الأوراق المالية
3. حل كبير آمن
4. كامل آمنه
#### معلومات اكثر:
* [إطار رشيق متدرج](https://en.wikipedia.org/wiki/Scaled_Agile_Framework)
* [ما هو آمن؟](http://www.scaledagileframework.com/what-is-safe/)
* [العناصر الأساسية العشر](http://www.scaledagileframework.com/essential-safe/)
* [مبادئ آمنة](http://www.scaledagileframework.com/safe-lean-agile-principles/)

46
guide/arabic/agile/scrum/index.md
View File

@ -1,46 +0,0 @@
---
title: Scrum
localeTitle: سكروم
---
## سكروم
Scrum هي واحدة من المنهجيات تحت مظلة Agile. يشتق الاسم من طريقة لاستئناف اللعب في رياضة الرجبي ، حيث يتحرك الفريق بأكمله معًا ليحرز مكانًا. وبالمثل ، فإن scrum في Agile ينطوي على جميع أجزاء الفريق التي تعمل على نفس مجموعة الأهداف. في طريقة scrum ، يتم عرض قائمة المهام ذات الأولوية على الفريق ، وعلى مدار "العدو" (عادة أسبوعين) ، يتم إكمال هذه المهام ، بالترتيب ، من قبل الفريق. هذا يضمن الانتهاء من المهام أو التسليمات ذات الأولوية القصوى قبل نفاد الوقت أو الأموال.
### مكونات سكروم
Scrum هي واحدة من المنهجيات تحت مظلة Agile. ينشأ من "scrummage" وهو مصطلح يستخدم في لعبة الركبي للإشارة إلى اللاعبين المتجمعين معا للحصول على الكرة. هذه الممارسة تدور حولها
* مجموعة من الأدوار (فريق التسليم ، مالك المنتج ، و scrum master)
* الاحتفالات (تخطيط العدو ، الاستعداد اليومي ، استعراض العدو ، الاستعراض السريع ، الاستمالة المتراكبة)
* التحف (تراكم المنتجات ، تراكمات العدو ، زيادة المنتج ، ومشعات المعلومات والتقارير).
* الهدف الرئيسي هو الحفاظ على محاذاة الفريق حول تقدم المشروع لتسهيل التكرار السريع.
* اختارت العديد من المنظمات Scrum ، لأنه على عكس نموذج الشلال ، فإنه يضمن التسليم في نهاية كل سبرينت.
## الآثار
* Sprint: هي المدة الزمنية ، معظمها في الأسابيع ، والتي يعمل فيها فريق لتحقيق أو إنشاء نتيجة. يمكن تعريف الناتج على أنه جزء من شفرة جزء من المنتج النهائي الذي يريد الفريق تحقيقه. ينصح Scrum بإبقاء مدة Sprint بين 2-4 أسابيع.
* تراكم المنتج: هي قائمة المهام التي من المفترض أن ينتهي فريق العمل بها ضمن Sprint الحالي. تقرر من قبل مالك المنتج ، بالاتفاق مع الإدارة بالإضافة إلى فريق التسليم.
## الأدوار
* مالك المنتج (صندوق البريد): الشخص المسؤول فقط إلى الإدارة. PO تقرر ما يدخل أو يخرج من تراكم المنتج.
* فريق التسليم: مطلوب منهم العمل وفقًا للمهام المحددة بواسطة أمر الشراء الخاص بهم في تراكم المنتج وتسليم الحوافز المطلوبة في نهاية السباق.
* Scrum Masters: - Scrum Master يجب أن تلتزم بصرامة بدليل Scrum وأن تجعل الفريق يفهم الحاجة إلى الالتزام بدليل Scrum عند اتباع Scrum. إنها مهمة سكرام ماستر لضمان أن جميع حفلات سكروم تجري في الوقت المحدد وشارك فيها جميع الأشخاص المطلوبين حسب دليل سكروم. يجب على SM ضمان أن يتم إجراء Daily Scrum بشكل منتظم ومشاركتها بنشاط من قبل الفريق.
#### معلومات اكثر:
هناك العديد من الأدوات عبر الإنترنت التي يمكن استخدامها لإجراء scrum لفريقك:
* [Scrum هل](https://www.scrumdo.com/)
* [أسانا](http://www.asana.com)
* [Trello](http://trello.com)
* [الإثنين](https://monday.com)
* [معسكر القاعدة](https://basecamp.com)
* [Airtable](https://airtable.com)
* [ورقة ذكية](https://www.smartsheet.com)
في ما يلي بعض الموارد الإضافية:
* [لماذا سكروم](https://www.scrumalliance.org/why-scrum) من مجتمع سكروم
* [دليل سكروم](http://www.scrumguides.org/scrum-guide.html) من Scrum.org
* [القيام مقابل كونها رشيقة](http://agilitrix.com/2016/04/doing-agile-vs-being-agile/)

34
guide/arabic/agile/scrummasters/index.md
View File

@ -1,34 +0,0 @@
---
title: Scrummasters
localeTitle: Scrummasters
---
## سكروم ماستر
The Scrum Master مسؤولة عن ضمان فهم Scrum وسنّها. يقوم Scrum Masters بذلك عن طريق ضمان التزام فريق Scrum بنظرية Scrum والممارسات والقواعد.
The Scrum Master هو قائد خادم لفريق Scrum. يساعد Scrum Master الأشخاص خارج Scrum Team على فهم أي من تفاعلاتهم مع فريق Scrum مفيدة وأيها غير متوفرة. يساعد Scrum Master كل شخص على تغيير هذه التفاعلات لتعظيم القيمة التي أنشأها فريق Scrum.
### سكروم ماجستير وظيفة
* تسهيل (غير مشارك في) الاستعداد اليومي
* مساعدة الفريق على الحفاظ على الرسم البياني للحرق
* وضع ما بعد الاسترجاعات ، استعراض السباق أو دورات تخطيط العدو
* حماية الفريق من الانقطاعات أثناء العدو
* إزالة العقبات التي تؤثر على الفريق
* المشي على مالك المنتج من خلال المزيد من قصص المستخدمين الفنية
* تشجيع التعاون بين فريق سكروم ومالك المنتج.
عادة ما سيسألك Scrummaster عن العقود التالية:
1. ماذا فعلت البارحة؟
2. ماذا ستفعل اليوم؟
3. هل هناك شيء يوقف تقدمك؟
أسياد سكروم هي جزء من فريق أجيل. يمكن أن يكونوا مطورين أو أعضاء وظيفيين آخرين (يرتدون قبعات متعددة) أو يعملون بشكل فردي كدور وحيد في الفريق. هدفهم الرئيسي هو تعزيز التنمية باستخدام إطار سكروم.
غالبًا ما يتمثل دورهم في: توجيه التخطيط السريع ، ومراقبة الاستعدادات اليومية ، وإجراء عمليات استعادة الأحداث ، وضمان السرعة ، والمساعدة في تحديد السرعة.
#### معلومات اكثر:
* [ما هو سكروم ماستر](https://www.scrum.org/resources/what-is-a-scrum-master)
* [دليل سكروم](https://www.scrum.org/resources/scrum-guide)

25
guide/arabic/agile/self-organization/index.md
View File

@ -1,25 +0,0 @@
---
title: Self Organization
localeTitle: التنظيم الذاتي
---
## التنظيم الذاتي
من أجل الحفاظ على ديناميكية عالية وخفة الحركة للمشاريع المتطورة ، يجب على جميع أعضاء الفريق أن يتحملوا المسؤولية عن المنتج الجاري تطويره.
أثبتت الهياكل التنظيمية الموجهة عموديا نفسها لتكون بطيئة وغير مرنة مع العديد من مستويات صنع القرار. إذا أراد فريق العمل بسرعة والرد بشكل حيوي على البيئة المتغيرة باستمرار ، فيجب أن يكون الهيكل التنظيمي ثابتًا مع شعور الأعضاء المسئولين بشدة عن مساهماتهم في المشروع.
هذا لا يعني أن الإدارة عملية عفا عليها الزمن في فريق منظم ذاتي رشيق. إنه يتميز بخاصية مختلفة عن النهج التقليدي (خاصة في المنظمات الكبيرة ، ولكن ليس فقط) ، يثبت أنه أكثر فعالية عندما يكون أكثر دعماً واستشارياً من الاستبداد والمباشر.
مؤسسة التنظيم الذاتي هي الثقة والالتزام من أعضاء الفريق.
يقال إن فرق سكرم هي منظمة ذاتية التنظيم. هذا يعني أن العمل المنجز وبصفة عامة طريقة عمله متروك للفريق ليقرر - هم تمكينهم من قبل مديريهم لتوجيه أنفسهم في الطرق التي تجعلها أكثر فعالية. أعضاء الفريق (فريق التسليم ، مالك المنتج ، و Scrum Master) يفحص سلوكياتهم بشكل منتظم للتحسين المستمر.
خلال تخطيط Sprint ، سينظر الفريق في تراكم المنتج (الذي سيتم تحديد أولوياته من قِبل مالك المنتج) وتحديد القصص التي سيعمل في العدو القادم والمهام التي ستحتاج إلى إكمال لتمييز القصة كما تم. سيقوم الفريق بتقدير درجة أو حجم لل قصة للدلالة على الجهد.
خلال عدو سريع ، يعود الأمر لأعضاء الفريق لاختيار قصص تراكم السباق للعمل عليها ، وعادةً ما يقومون باختيار تلك التي يعتقدون أنها تستطيع التوصل. نظرًا لكونه فريقًا للتنظيم الذاتي ، يجب ألا يتم تعيين أي مهمة لأحد أعضاء الفريق بواسطة شخص آخر.
#### معلومات اكثر:
* Scrum.org على [Scrum تعزيز التنظيم الذاتي](https://www.scrum.org/resources/blog/how-does-scrum-promote-self-organization)
* Scrum.org على [أدوار Scrum تعزيز التنظيم الذاتي](https://www.scrum.org/resources/blog/how-do-3-scrum-roles-promote-self-organization)
* Scrum التحالف على [ماذا وكيف التنظيم الذاتي](https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how)

22
guide/arabic/agile/spikes/index.md
View File

@ -1,22 +0,0 @@
---
title: Spikes
localeTitle: المسامير
---
## المسامير
ليس كل ما يعمل عليه فريقك خلال Sprint هي "قصص المستخدم". في بعض الأحيان ، لا يمكن تقدير قصة المستخدم بفاعلية أو أن البحث مطلوب. ربما تكون هناك حاجة للمساعدة في اتخاذ قرار بين البنى المختلفة ، لاستبعاد بعض المخاطر ، أو قد يكون إثبات للمفهوم (POC) لإثبات القدرة.
في هذه الحالات ، يتم إضافة سبايك إلى تراكم سبرينت. يجب أن تكون معايير القبول الخاصة بالسبايك إجابة على السؤال المطروح. إذا كانت التجربة أصعب من المتوقع ، فقد تكون الإجابة سلبية. (لهذا السبب يجب أن تكون سبايك محدودة في الوقت المناسب.)
يتم تحديد الوقت والطاقة المستثمرة في Spike بشكل مقصود بحيث يمكن إكمال العمل داخل Sprint بينما يتم التأثير بشكل طفيف على "قصص المستخدم الأخرى". لا يحصل Spike عادةً على Story Point Estimate ، ولكنه يُمنح عدد محدد من الساعات ليتم العمل عليه.
إظهار نتائج Spike في استعراض Sprint. استنادًا إلى المعلومات الجديدة ، يتم إعادة صياغة السؤال الأصلي كقصة مستخدم جديدة في سباق مستقبلي.
حصل فريقك على المعلومات اللازمة لاتخاذ قرارات أفضل ؛ للحد من عدم اليقين. مع كمية صغيرة ومقيسة من مواردها لزيادة جودة وقيمة العمل في سباقات السرعة في المستقبل ، بدلا من اتخاذ القرارات على أساس التخمين العمل.
#### معلومات اكثر:
* جبل الماعز البرمجيات [المسامير](https://www.mountaingoatsoftware.com/blog/spikes)
* المنتدى Scrum.org [كيفية دمج سبايك](https://www.scrum.org/forum/scrum-forum/5512/how-integrate-spike-scrum)
* Scrum Alliance [Spikes and Effort-to-Grief Ratio](https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio)
* ويكيبيديا [سبايك](https://en.wikipedia.org/wiki/Spike_(software_development))

13
guide/arabic/agile/sprint-backlog/index.md
View File

@ -1,13 +0,0 @@
---
title: Sprint Backlog
localeTitle: سباق المتراكمة
---
## سباق المتراكمة
إن Sprint Backlog هي قائمة من المهام التي حددها فريق Scrum لإكمالها أثناء Scrum Sprint. أثناء اجتماع Sprint Planning ، يقوم الفريق بتحديد عدد من عناصر تراكم المنتجات ، عادةً في شكل قصص المستخدمين ، ويحدد المهام اللازمة لإكمال كل قصة مستخدم.
من الأهمية بمكان أن يحدد الفريق نفسه عناصر وحجم Sprint Backlog. نظرًا لأنهم هم الأشخاص الذين يقومون بتنفيذ / إكمال المهام ، يجب أن يكونوا هم الأشخاص الذين يختارون ما يدعون إلى تحقيقه خلال سباق العدو.
#### معلومات اكثر:
[Scrum الدليل: Sprint Backlog](http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)

30
guide/arabic/agile/sprint-planning-meetings/index.md
View File

@ -1,30 +0,0 @@
---
title: Sprint Planning Meeting
localeTitle: اجتماع التخطيط سبرينت
---
## اجتماع التخطيط سبرينت
يتم تسريع تخطيط Sprint من قبل فريق Scrum Master ويتكون من فريق Scrum: فريق التطوير ، مالك المنتج (PO) و Scrum Master (SM). ويهدف إلى تخطيط مجموعة فرعية من عناصر تراكم منتج إلى تراكم Sprint. يبدأ Scrum Sprint عادة بعد اجتماع تخطيط Sprint.
### الجزء الرئيسي
من الأهمية بمكان أن يقوم الفريق بجزء من الاجتماع في جزئين من خلال طرح السؤالين التاليين:
* **ماذا** يجب على الفريق أن يخطط لسباق السرعة القادم؟
* **كيف** يجب على الفريق (تقريبًا) سحب العناصر المخطط لها؟
#### ماذا
في أي مرحلة يبدأ الفريق مع الجزء العلوي من Backlog المنتج المطلوب. الفريق على الأقل يقدر بشكل ضمني العناصر عن طريق التنبؤ بما يمكنهم أخذه إلى Sprint Backlog. إذا لزم الأمر ، يمكنهم طلب / مناقشة البنود مع أمر الشراء ، الذي يجب أن يكون في مكان مناسب لهذا الاجتماع.
#### ماذا
في المرحلة التي يناقشها الفريق في وقت قصير ، يختص كل عنصر تم تنزيله من Sprint ، مع التركيز على كيفية استيعابه. SM يساعد الفريق على عدم الغوص العميق في تفاصيل المناقشة والتنفيذ. من المحتمل جداً وجيد إذا طُلب المزيد من الأسئلة إلى أمر الشراء أو إدخال تحسينات على البنود ، أو عمل الفريق المتأخر.
### سبرينت الهدف / الخاتمة
يجب أن يأتي الفريق مع هدف Sprint مشترك من أجل Sprint للحفاظ على التركيز في مربع وقت Sprint. في نهاية تخطيط Sprint ، يتوقع الفريق أنه بإمكانه تحقيق هدف Sprint وإكمال جميع عناصر Sprint Backlog على الأرجح. يجب على SM منع الفريق من المبالغة في التقدير من خلال تقديم إحصاءات أو إحصاءات مفيدة.
#### معلومات اكثر:
[دليل سكروم: سبرت التخطيط](http://www.scrumguides.org/scrum-guide.html#events-planning) [ورقة الغش بسيطة لاجتماعات التخطيط العدو](https://www.leadingagile.com/2012/08/simple-cheat-sheet-to-sprint-planning-meeting/) [أربع خطوات لتخطيط سبرينت أفضل](https://www.atlassian.com/blog/agile/sprint-planning-atlassian)

19
guide/arabic/agile/sprint-planning/index.md
View File

@ -1,19 +0,0 @@
---
title: Sprint Planning
localeTitle: تخطيط العدو
---
## تخطيط العدو
في Scrum ، يحضر اجتماع تخطيط السباق من قبل مالك المنتج ، ScrumMaster وفريق Scrum بأكمله. قد يحضر أصحاب المصلحة الخارجيون بدعوة من الفريق ، على الرغم من أن هذا نادر في معظم الشركات. خلال اجتماع التخطيط السريع ، يصف مالك المنتج أعلى الميزات ذات الأولوية للفريق. يسأل الفريق أسئلة كافية حتى يتمكنوا من تحويل قصة مستخدم عالية المستوى من تراكم المنتج إلى المهام الأكثر تفصيلاً في تراكمات العدو.
هناك نوعان من التحف الفنية المحددة الناتجة عن اجتماع تخطيط سباق:
* هدف السباق
* تراكم سباق
تخطيط سبرينت هو محاصر بالوقت إلى حد أقصى من ثماني ساعات لمدة شهر واحد سبرينت. لسباقات قصيرة ، يكون الحدث أقصر عادة. يضمن سكروم ماستر أن الحدث سيحدث ويفهم المشاركون الغرض منه. تُعلِّم Scrum Master فريق Scrum للاحتفاظ بها ضمن مربع الوقت.
#### معلومات اكثر:
* https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-planning-meeting
* [دليل سكروم](http://www.scrumguides.org/scrum-guide.html)

29
guide/arabic/agile/sprint-review/index.md
View File

@ -1,29 +0,0 @@
---
title: Sprint Review
localeTitle: استعراض سبرينت
---
## استعراض سبرينت
استعراض Sprint هو واحد من الاحتفالات الرئيسية Scrum (جنبا إلى جنب مع Sprint Planning و Daily Stand Up و Retrospective و Grooming).
في نهاية لعبة Sprint ، يستضيف فريق Scrum جلسة "دعوة إلى العالم" لعرض ما تم إنجازه وقبوله. المدعوين هم فريق سكروم ، أصحاب المصلحة ، المديرون ، المستخدمون ؛ أي شخص لديه مصلحة في المشروع.
عقد هذه الجلسات كل سبرينت أمر مهم. قد يكون تحولًا في التفكير عرض العمل غير المكتمل لمديريك وأصحاب المصلحة. ولكن في مفهوم "Fail Fast" ، هناك قيمة لا تصدق في الحصول على تعليقات حول عملك المتزايد. يمكن لفريقك تصحيح الدورة التدريبية إذا لزم الأمر ، مع تقليل العمل المفقود.
نظرًا لأن مالك المنتج (PO) غالبًا ما يقدم في مراجعة Sprint ، فإن Scrum Master عادةً ما يلتقط التعليقات ، وربما يسهل المناقشات ، ثم يعمل مع أمر الشراء للحصول على قصص مستخدمين جديدة تمت إضافتها إلى الأعمال المتراكمة وترتيبها حسب الأولوية.
وقد يتضمن جدول الأعمال أيضًا مراجعة للحساب المتراكم (بما في ذلك القيمة والأولوية) ، والمقرر إجراؤه للتكرار التالي أو الاثنين ، وما يمكن إزالته من العمل المتراكم.
**هام** يختلف استعراض Sprint تمامًا عن Retrospective. إن إعادة التفكير بشكل صارم لفريق Scrum (سكروم ماستر ، PO وفريق التسليم). يتم إعفاء الأطراف الأخرى التي تمت دعوتها إلى المراجعة من ، و من المحتمل أن تتداخل معها ، بأثر رجعي. (نعم ، بما في ذلك المديرون).
#### معلومات اكثر:
كين روبن من فوليولايشن [ستوب](https://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte) كولينج سبرينتك [استعراض تجريبي](https://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte)
Scrum.org [ما هو استعراض العدو](https://www.scrum.org/resources/what-is-a-sprint-review)
الجبل الماعز البرمجيات [استعراض سبرينت الاجتماع](https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting)
اتلسيان [ثلاث خطوات](https://www.atlassian.com/blog/agile/sprint-review-atlassian) لمراجعات [أفضل سبرينت](https://www.atlassian.com/blog/agile/sprint-review-atlassian)
العمر من المنتج [استعراض مكافحة الانماط](https://age-of-product.com/sprint-review-anti-patterns/)

21
guide/arabic/agile/sprints/index.md
View File

@ -1,21 +0,0 @@
---
title: Sprints
localeTitle: سباقات السرعة
---
## سباقات السرعة
في Scrum ، تكون **Sprint** عبارة عن فترة زمنية تتراوح عادةً بين أسبوع وأربعة أسابيع يعمل فيها فريق التوصيل على مشروعك. تكون السباقات متكررة ، وتستمر حتى اكتمال المشروع. يبدأ كل سباق بجلسة Sprint Planning وينتهي باجتماع Sprint Review و Retrospective. استخدام سباقات السرعة ، بدلاً من الشلال الذي استمر لمدة شهور أو منهجيات متسلسلة خطية متتالية ، يسمح بعمليات تغذية مرتدة منتظمة بين مالكي المشروع وأصحاب المصلحة حول ناتج فريق التوصيل.
## خصائص سباق
\- يجب أن تظل المطبوعات بنفس طول الفترة الزمنية المحددة طوال مدة المشروع. - يعمل الفريق على تفكيك "قصص المستخدم" إلى حجم يمكن إكماله خلال مدة "سبرينت" دون الانتقال إلى المرحلة التالية. - غالبًا ما يتم استخدام "Sprint" و "Iteration" بالتبادل.
#### معلومات اكثر:
* تحالف رشيق على [التكرارات](https://www.agilealliance.org/glossary/iteration/)
* تحالف رشيق على [Timeboxes](https://www.agilealliance.org/glossary/timebox/)
* المدرب رشيق على [سبرينت مقابل التكرار](http://agilecoach.typepad.com/agile-coaching/2014/02/sprint-vs-iteration.html)
* Scrum Alliance [Timeboxing كعامل تحفيزي](https://www.scrumalliance.org/community/articles/2014/february/timeboxing-a-motivational-factor-for-scrum-teams)
* Scrum Alliance [Sprint هو أكثر من مجرد Timebox](https://www.scrumalliance.org/community/articles/2014/may/sprint-is-more-than-just-a-timebox)
* Scrum Inc [ما هو Timeboxing](https://www.scruminc.com/what-is-timeboxing/)
* Scrum.org [ما هو سباق في سكروم](https://www.scrum.org/resources/what-is-a-sprint-in-scrum)

22
guide/arabic/agile/stakeholders/index.md
View File

@ -1,22 +0,0 @@
---
title: Stakeholders
localeTitle: أصحاب المصلحة
---
## أصحاب المصلحة
أصحاب المصلحة هم الأشخاص الذين سيستفيدون من مشروعك. الأمر متروك لمالك المنتج لفهم النتيجة المطلوبة من قبل أصحاب المصلحة ، ولإبلاغ هذه الحاجة إلى فريق التسليم. يمكن أن يتكون أصحاب المصلحة من أي مما يلي
* المستخدمين
* الزبائن
* مدراء
* الممولين / المستثمرين
مشاركتهم في المشروع أمر ضروري للنجاح.
على سبيل المثال ، عندما يقوم فريقك بإجراء اجتماعات استعراض Sprint ، فإن العرض التوضيحي للمشروع مخصص لأصحاب المصلحة ، ويتم التقاط تعليقاتهم وإضافتها إلى الأعمال المتراكمة.
#### معلومات اكثر:
* Scrum Study [أصحاب المصلحة في سكروم](https://www.scrumstudy.com/blog/stakeholders-in-scrum/)
* [أصحاب المصلحة الرئيسيون](https://www.scrum.org/resources/blog/scrum-who-are-key-stakeholders-should-be-attending-every-sprint-review)
* النمذجة رشيقة [المشاركة الفعالة لأصحاب المصلحة](http://agilemodeling.com/essays/activeStakeholderParticipation.htm)

25
guide/arabic/agile/story-points-and-complexity-points/index.md
View File

@ -1,25 +0,0 @@
---
title: Story Points and Complexity Points
localeTitle: نقاط القصة ونقاط التعقيد
---
## نقاط القصة ونقاط التعقيد
في Scrum / Agile ، يتم استكشاف وظائف المنتج قيد التطوير من خلال **القصص التي** قد يخبرها المستخدم عن ما يريده من المنتج. يستخدم فريق **Story Points** عند تقدير مقدار الجهد المطلوب لتقديم قصة مستخدم.
الملامح البارزة لنقاط القصة هي أنها:
* تمثل مساهمات الفريق بأكمله
* لا تساوي مباشرة الوقت الذي قد تستغرقه المهمة
* هي مقياس تقريبي لأغراض التخطيط - على غرار أوامر الحجم
* يتم تعيينها في تسلسل تشبه فيبوناتشي: 0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 20 ، 40 ، 100
* تقدير "حجم" القصص _المتعلقة ببعضها البعض_
يمكن لمفهوم نقاط القصة أن يكون بعيد المنال إذا كنت جديدا على طرق Agile للقيام بالأشياء. ستجد العديد من المصادر على الإنترنت تناقش نقاط القصة بطرق مختلفة ، وقد يكون من الصعب الحصول على فكرة واضحة عن كيفية استخدامها وكيفية استخدامها.
كما تعلم عن مبادئ ومصطلحات الممارسات مثل سكروم ، فإن أسباب بعض هذه الخصائص تصبح واضحة. إن استخدام نقاط القصة ، لا سيما في "الاحتفالات" مثل التخطيط للبوكر ، هو أسهل بكثير من خلال الملاحظة أو المشاركة أكثر من الشرح المكتوب!
### معلومات اكثر:
* قصص المستخدم: [freeCodeCamp](https://guide.freecodecamp.org/agile/user-stories)
* الأخطاء الشائعة عند استخدام نقاط القصة: [متوسط](https://medium.com/bynder-tech/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7)
* تخطيط لعبة البوكر: [جبل الماعز البرمجيات](https://www.mountaingoatsoftware.com/agile/planning-poker)

11
guide/arabic/agile/sustainable-pace/index.md
View File

@ -1,11 +0,0 @@
---
title: Sustainable Pace
localeTitle: وتيرة المستدامة
---
## وتيرة المستدامة
A Pace المستدامة هي الوتيرة التي يمكن أن تعمل أنت وفريقك لفترات طويلة ، حتى إلى الأبد. يحترم عطلتك الأسبوعية ، والأمسيات ، والعطلات ، والإجازات. يسمح للاجتماعات اللازمة ووقت التطوير الشخصي.
#### معلومات اكثر:
[ما هو "بيس بيسينج"؟](http://www.sustainablepace.net/what-is-sustainable-pace)

35
guide/arabic/agile/task-boards-and-kanban/index.md
View File

@ -1,35 +0,0 @@
---
title: Task Boards and Kanban
localeTitle: لوحات المهام و Kanban
---
## لوحات المهام و Kanban
Kanban هو وسيلة ممتازة لكل من فرق تطوير البرمجيات والأفراد تتبع مهامهم الشخصية.
إذا كنت مشتقًا من المصطلح الياباني لـ "لافتة" أو "لوحة إعلانات" لتمثيل إشارة ، فإن المفتاح الرئيسي هو الحد من عملك قيد التقدم (WIP) إلى عدد محدود من المهام في وقت معين. يتم تحديد المبلغ الذي يمكن أن يكون قيد التنفيذ من خلال قدرة الفريق (أو الفرد) المقيدة. عندما تنتهي مهمة واحدة ، هذه إشارة لك لتحريك مهمة أخرى إلى مكانها.
يتم عرض مهام Kanban على لوحة المهام في سلسلة من الأعمدة التي تظهر حالة المهام. في أبسط أشكالها ، يتم استخدام ثلاثة أعمدة
* لكى يفعل
* فعل
* فعله
![مثال مجلس كانبان](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Simple-kanban-board-.jpg/600px-Simple-kanban-board-.jpg)
_الصورة مجاملة من [ويكيبيديا](https://en.wikipedia.org/wiki/Kanban_board)_
ولكن يمكن إضافة العديد من الأعمدة أو الولايات الأخرى. قد يتضمن فريق البرامج أيضًا انتظار الاختبار أو الاكتمال أو المقبولة ، على سبيل المثال.
![المزيد من الأمثلة المعقدة](https://mktgcdn.leankit.com/uploads/images/general/_2048xAUTO_fit_center-center/1-SmalDevelopmentTeamKanbanBoard-eb79376d.png)
_الصورة مجاملة من [leankit](https://leankit.com/learn/kanban/kanban-board-examples-for-development-and-operations/)_
### معلومات اكثر:
* ما هو [كانبان](https://leankit.com/learn/kanban/what-is-kanban/) : [لينكيت](https://leankit.com/learn/kanban/what-is-kanban/)
* ما هو كانبان: [أتلاسيان](https://www.atlassian.com/agile/kanban)
بعض المجالس على الانترنت
* [Trello](https://trello.com/)
* [KanbanFlow](https://kanbanflow.com)

16
guide/arabic/agile/technical-debt/index.md
View File

@ -1,16 +0,0 @@
---
title: Technical Debt
localeTitle: الديون الفني
---
## الديون الفني
في كثير من الأحيان في تطوير رشيق ، إذا كنت تنتج برامج في الممارسة "جيدة بما فيه الكفاية" ، سوف تضيف أيضا إلى الديون التقنية الخاصة بك. هذا هو تراكم اختصارات قصيرة والعمل.
قارنها بالمال. عندما تتقاضى شيئًا من بطاقة ائتمان ، تكون قد تعهدت بدفعه لاحقًا. عندما تنشئ دينًا تقنيًا ، _يجب أن_ يلتزم فريقك بمعالجة هذه المشكلات وفقًا لجدول زمني.
تتمثل إحدى فوائد العمل بشكل متكرر في عرض الزيادات بشكل متكرر وجمع التعليقات. إذا كان تمريرك الأول "جيدًا بما فيه الكفاية" ، والتغييرات مطلوبة نتيجة لتلك التعليقات ، فقد تكون قد تجنبت بعض العمل غير الضروري. التقاط هذا في backlog الخاص بك ، وتضمين جزء في كل سبرينت ليتم إعادة تصنيعها أو تحسينها.
#### معلومات اكثر:
* تحالف Agile على [الديون الفنية](https://www.agilealliance.org/introduction-to-the-technical-debt-concept/)
* Scrum التحالف على [إدارة الديون التقنية](https://www.scrumalliance.org/community/articles/2013/july/managing-technical-debt)

38
guide/arabic/agile/test-driven-development/index.md
View File

@ -1,38 +0,0 @@
---
title: Test Driven Development
localeTitle: اختبار مدفوعة التطوير
---
## اختبار مدفوعة التطوير
التطوير المدفوع بالاختبار (TDD) هو أحد مناهج تطوير البرمجيات Agile. ويستند على مفهوم أن
> يجب أن تكتب حالة اختبار للشفرة حتى قبل كتابة الشفرة
هنا ، نكتب اختبار الوحدة أولاً ثم نكتب الكود لإكمال الاختبار بنجاح. وهذا يوفر الوقت المستغرق لإجراء اختبار الوحدة واختبار آخر مماثل ، لأننا نمضي قدمًا في التكرار الناجح للاختبار بالإضافة إلى تحقيق نمطية في الشفرة. انها اساسا تتكون من 4 خطوات
* اكتب حالة اختبار
* انظر فشل الاختبار (الأحمر)
* جعل تمرير الاختبار ، أي ما يرافق أي جرائم في هذه العملية (الأخضر)
* ريفاكتور الكود الذي يصل إلى المعايير (ريفاكتور)
هذه الخطوات تتبع مبدأ الأحمر-الأخضر-ريفاكتور. الأحمر والأخضر تأكد من كتابة أبسط رمز ممكن لحل المشكلة في حين أن الخطوة الأخيرة تتأكد من أن الكود الذي تكتبه متروك للمعايير.
يجب أن تتبع كل ميزة جديدة في النظام الخاص بك الخطوات المذكورة أعلاه.
![تدفق tdd](http://www.agiledata.org/images/tddSteps.jpg)
#### معلومات اكثر:
[مقدمة](http://agiledata.org/essays/tdd.html) رشيقة البيانات [إلى TDD](http://agiledata.org/essays/tdd.html)
ويكي على [TDD](https://en.wikipedia.org/wiki/Test-driven_development)
مارتن فاولر [هو TDD ميت؟](https://martinfowler.com/articles/is-tdd-dead/) (سلسلة من المحادثات المسجلة حول الموضوع)
كتاب كينت بيك [للتطوير المدفوع من خلال المثال](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530)
العم بوب في [دورات TDD](http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html)

42
guide/arabic/agile/the-agile-manifesto/index.md
View File

@ -1,42 +0,0 @@
---
title: The Manifesto
localeTitle: البيان
---
## البيان
### الأصل
> في يوم 11-13 فبراير 2001 ، في منتجع لودج آت سنوبيرد للتزلج في جبال واساتس في يوتا ، التقى سبعة عشر شخصًا للحديث ، والتزلج ، والاسترخاء ، ومحاولة إيجاد أرضية مشتركة - وبالطبع ، لتناول الطعام. \[…\] الآن ، سيكون من الصعب العثور على تجمع أكبر للأناركيين التنظيميين ، لذا فإن ما خرج من هذا الاجتماع كان رمزيًا - بيانًا لتطور برامج Agile - وقعه جميع المشاركين. (1)
### بيان لتطوير البرمجيات رشيقة
نحن نكشف عن طرق أفضل لتطوير البرمجيات من خلال القيام بذلك ومساعدة الآخرين على القيام بذلك.
من خلال هذا العمل ، وصلنا إلى قيمة
* **الأفراد والتفاعلات** على العملية والأدوات.
* **برنامج العمل** على وثائق شاملة.
* **تعاون العملاء** على التفاوض بشأن العقود.
* **الاستجابة للتغيير** بعد اتباع الخطة.
في حين أن هناك قيمة في العناصر على اليمين ، فإننا نقدر العناصر على اليسار أكثر.
### اثنا عشر مبادئ من رشيق البرمجيات
1. إن أولويتنا القصوى هي إرضاء العميل من خلال تقديم برامج قيمة في وقت مبكر ومستمر.
2. نرحب المتطلبات المتغيرة، حتى وقت متأخر في التنمية. تساهم العمليات السريعة في تغيير الميزة التنافسية للعميل.
3. تقديم برامج العمل في كثير من الأحيان ، من بضعة أسابيع إلى بضعة أشهر ، مع تفضيل لفترة زمنية أقصر.
4. يجب على رجال الأعمال والمطورين العمل معا يوميا في جميع أنحاء المشروع.
5. بناء مشاريع حول دوافع الأفراد. أعطهم البيئة والدعم الذي يحتاجون إليه ، وثق بهم لإنجاز المهمة.
6. إن الطريقة الأكثر فعالية وفعالية لنقل المعلومات إلى فريق التطوير وداخله هي المحادثة المباشرة.
7. يعمل البرنامج هو المقياس الأساسي للتقدم.
8. عمليات رشيقة تعزز التنمية المستدامة. يجب على مقدمي المشروع والمطورين والمستخدمين الحفاظ على وتيرة ثابتة إلى أجل غير مسمى.
9. الاهتمام المستمر بالتميز الفني والتصميم الجيد يعزز من الرشاقة.
10. البساطة - فن تعظيم كمية العمل التي لم يتم القيام بها - أمر ضروري.
11. تنشأ أفضل البنى والمتطلبات والتصاميم من فرق التنظيم الذاتي.
12. في الفترات المنتظمة ، يتأمل الفريق في كيفية أن يصبح أكثر فعالية ، ثم يضبط ويعدل سلوكه وفقًا لذلك.
#### معلومات اكثر:
* [(1) التاريخ: The Agile Manifesto](http://agilemanifesto.org/history.html)
* [بيان أجيل](http://agilemanifesto.org/)

54
guide/arabic/agile/user-acceptance-tests/index.md
View File

@ -1,54 +0,0 @@
---
title: User Acceptance Tests
localeTitle: اختبارات قبول المستخدم
---
## اختبارات قبول المستخدم
في الهندسة ومختلف فروعها ، اختبار القبول هو اختبار تم إجراؤه لتحديد ما إذا كانت متطلبات المواصفة أو العقد قد تم الوفاء بها. قد تتضمن اختبارات كيميائية أو اختبارات فيزيائية أو اختبارات أداء.
في هندسة الأنظمة ، قد يتضمن اختبار الصندوق الأسود على نظام (على سبيل المثال: قطعة من البرمجيات ، أو الكثير من الأجزاء الميكانيكية المصنعة ، أو دفعات من المنتجات الكيميائية) قبل تسليمها.
في اختبار البرمجيات ، يعرف ISTQB القبول على النحو التالي: الاختبار الرسمي فيما يتعلق باحتياجات المستخدم ، ومتطلباته ، وعمليات الأعمال التي أجريت لتحديد ما إذا كان النظام يلبي معايير القبول ولتمكين المستخدم أو العملاء أو الكيان المعتمد الآخر لتحديد ما إذا كان سيتم قبول أو عدم قبول النظام. يعرف اختبار القبول أيضاً باختبار قبول المستخدم (UAT) ، واختبار المستخدم النهائي ، واختبار القبول التشغيلي (OAT) أو اختبار المجال (القبول).
يمكن استخدام اختبار الدخان كاختبار قبول قبل تقديم بنية من البرامج إلى عملية الاختبار الرئيسية.
واحدة من الخطوات النهائية في اختبار البرمجيات هي اختبار قبول المستخدم (UAT). UAT يتأكد من أن المستخدمين الفعليين يمكنهم استخدام البرنامج. يُشار أيضًا إلى الاختبار التجريبي والتطبيق واختبار المستخدم النهائي.
يتحقق UAT أن كل شيء يعمل بشكل صحيح وأنه لا توجد حوادث. ينبغي على الجمهور المستهدف إكمال الاختبار ؛ يمكن أن يتكون هذا من العديد من الأشخاص المشاركين في العملية وأي شخص قادر على الاختبار قبل بدء البث المباشر. يتم إرسال التعليقات الواردة من هذا الاختبار إلى فريق التطوير لأي تغييرات محددة.
#### لماذا نحتاج UAT
* تغييرات المتطلب قد لا تكون قد أبلغت للمطورين
* قد لا يتم تقديم البرنامج في الواقع لما يعنيه
* قد تحتاج بعض المنطق أو العملية التجارية إلى اهتمام المستخدم
#### ما هو مطلوب قبل أن نبدأ UAT
* تم التوقيع على requriement كاملة ومتاحة كما هو موثق
* الرمز قيد العمل أو في حالة قابلة للتطبيق
* UAT هي بيئة جاهزة للوصول
* يجب ألا يكون هناك أي عيب والذي سيؤدي إلى كسر الشفرة
* بيانات اختبار أعدت وفقا ل scneario LIVE
#### الإطار والأدوات المستخدمة
* FitNesse
#### مقالات حول UAT
* [7 مفاتيح إلى اختبار قبول المستخدم الناجح](http://blog.debugme.eu/successful-user-acceptance-testing/)
* [AgileUAT: إطار لاختبار قبول المستخدم استنادًا إلى قصص المستخدم ومعايير القبول](http://research.ijcaonline.org/volume120/number10/pxc3903533.pdf)
#### معلومات اكثر:
https://en.wikipedia.org/wiki/Acceptance\_testing

28
guide/arabic/agile/user-stories/index.md
View File

@ -1,28 +0,0 @@
---
title: User Stories
localeTitle: قصص المستخدم
---
تعد قصص المستخدمين جزءًا من نهج سريع يساعد على تحويل التركيز من الكتابة عن المتطلبات إلى التحدث عنها. تتضمن جميع قصص المستخدمين الذكية جملة مكتوبة أو اثنتين ، والأهم من ذلك ، سلسلة من المحادثات حول الوظيفة المطلوبة.
تتم كتابة قصص المستخدمين عادةً باستخدام النمط التالي:
#### بصفتي \[نوع من المستخدمين\] ، أريد \[بعض الأهداف\] حتى \[بعض الأسباب أو الحاجة\]
يجب كتابة قصص المستخدمين بعبارات غير فنية من وجهة نظر المستخدم. يجب أن تؤكد القصة على حاجة المستخدم ، وليس كيف. يجب ألا يكون هناك حل متوفر في قصة المستخدم.
يتم كتابة خطأ شائع واحد عند كتابة قصص المستخدمين من منظور المطور أو الحل. تأكد من تحديد الهدف والحاجة ، وستأتي المتطلبات الوظيفية لاحقًا.
#### تحجيم قصة مستخدم: الملاحم والقصص الأصغر
الملحمة هي قصة كبيرة خشنّة. يتم تقسيمها عادةً إلى العديد من قصص المستخدمين على مدار الوقت - مما يعزز ردود فعل المستخدمين على النماذج الأولية المبكرة والزيادات في المنتجات. يمكنك التفكير في ذلك كعنوان رئيسي وعنصر نائب لمزيد من القصص التفصيلية.
بدءا من الملاحم يسمح لك لرسم وظائف المنتج دون الالتزام بالتفاصيل. هذا مفيد بشكل خاص لوصف المنتجات والميزات الجديدة: إنه يسمح لك بالتقاط النطاق الخام ، ويشتري لك الوقت لمعرفة المزيد حول كيفية تلبية احتياجات المستخدمين على أفضل وجه.
كما يقلل من الوقت والجهد اللازمين لدمج رؤى جديدة. إذا كان لديك العديد من القصص التفصيلية في تراكم المنتجات ، فغالباً ما يكون من الصعب ومستهلكًا للوقت ربط التعليقات بالعناصر المناسبة وينطوي على مخاطر إدخال التناقضات.
عند التفكير في قصص محتملة ، من المهم أيضًا مراعاة "حالات إساءة الاستخدام" و "المسار غير السار". كيف سيتم التعامل مع الاستثناءات من قبل النظام؟ ما نوع الرسائل التي ستقدمها للمستخدم؟ كيف يمكن أن يقوم مستخدم ضار بإساءة استخدام وظيفة التطبيق هذه؟ هذه القصص يمكن أن تنقذ إعادة العمل وتصبح حالات اختبار مفيدة في ضمان الجودة.
#### معلومات اكثر:
* [دليل الماعز الجبلي لقصص المستخدم](https://www.mountaingoatsoftware.com/agile/user-stories)
* [رومان Pichler دليل لقصص المستخدم](http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/)

17
guide/arabic/agile/value-stream-mapping/index.md
View File

@ -1,17 +0,0 @@
---
title: Value Stream Mapping
localeTitle: رسم الخرائط تيار القيمة
---
## رسم الخرائط تيار القيمة
**تخطيط دفق القيمة** هو تقنية تطوير برمجي. يساعد على تحديد النفايات في الموارد من حيث المواد والجهد والتكلفة والوقت.
يعد حساب كفاءة دورة العمليات إحدى الطرق لاكتشاف كفاءة عملية AS-IS.
**كفاءة دورة العمليات = الوقت المستغرق في القيمة المضافة / الوقت الإجمالي للدورة.**
كلما زادت القيمة كلما كانت الكفاءة أفضل.
#### معلومات اكثر:
* [ويكيبيديا](https://en.wikipedia.org/wiki/Value_stream_mapping)

27
guide/arabic/agile/vanity-metrics/index.md
View File

@ -1,27 +0,0 @@
---
title: Vanity Metrics
localeTitle: مقاييس الغرور
---
## مقاييس الغرور
عندما تكون Vanity هي قيمة المظهر على الجودة ، فإن Vanity Metrics عبارة عن قياسات تستخدم ، دون سياق أو تفسير ، لجعل شخص ما أو شيء ما يبدو جيدًا. يشير إريك ريس ، الذي نشر في " [هارفارد بيزنس ريفيو"](https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics) ، إلى أن المقاييس يجب أن تكون **قابلة للتنفيذ** ، **ويمكن الوصول إليها** ، وأن تكون **قابلة للتدقيق** لكي يكون لها معنى.
![مقاييس الغرور](https://i.pinimg.com/originals/d4/ea/9a/d4ea9ade0de05a5707e11b325a37d5fb.jpg)
أمثلة:
* المستخدمون المسجلون مقابل المستخدمين النشطين
* قصص المستخدمين المقبولة مقابل القيمة المقدمة للعميل
* أتباع التغريد مقابل ريتويتيد
![مسائل القيمة](https://blog.kissmetrics.com/wp-content/uploads/2012/01/increasing-pageviews-flat-revenues.png) _الصورة عن طريق kissmetrics_
#### معلومات اكثر:
Fizzle على Actionable [vs Vanity Metrics](https://fizzle.co/sparkline/vanity-vs-actionable-metrics)
Harvard Business Review on [Vanity Metrics](https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics)
Forbes [Ignore Vanity Metrics and Focus on Engagement](https://www.forbes.com/sites/sujanpatel/2015/05/13/why-you-should-ignore-vanity-metrics-focus-on-engagement-metrics-instead/#1342fdeb12a9)
القذف [بعيدا بعيدا الغرور القياسات](https://blog.kissmetrics.com/throw-away-vanity-metrics/)

13
guide/arabic/agile/velocity/index.md
View File

@ -1,13 +0,0 @@
---
title: Velocity
localeTitle: ● السرعة
---
## ● السرعة
على فريق Scrum ، يمكنك تحديد السرعة في نهاية كل تكرار. إنه ببساطة مجموع نقاط Story مكتملة داخل timebox.
إن وجود سرعة متوقعة وثابتة تسمح لفريقك بالتخطيط للتكرار الخاص بك مع بعض الثقة ، والعمل بشكل مستدام ، والتنبؤ ، مع البيانات التجريبية ، بحجم النطاق المطلوب تضمينه في كل إصدار.
#### معلومات اكثر:
تحالف سكروم على [السرعة](https://www.scrumalliance.org/community/articles/2014/february/velocity)

14
guide/arabic/agile/voice-of-the-customer/index.md
View File

@ -1,14 +0,0 @@
---
title: Voice of the Customer
localeTitle: صوت الزبون
---
## صوت الزبون
أنت ، بصفتك مالك المنتج (PO) ، هي صوت العميل إلى فريق التسليم. عندما يحتاج الفريق إلى توضيح حول قصة ، لفهم "ماذا ولماذا" بشكل أفضل ، سيطلبون منك ذلك.
أنت تفهم الاحتياجات والدوافع والنتائج المرجوة للعميل أثناء تغييرها على طول المشروع.
#### معلومات اكثر:
تحالف سكروم على [مالك المنتج](https://www.scrumalliance.org/community/articles/2014/july/who-is-your-product-owner)
Agile Alliance على [مالك المنتج](https://www.agilealliance.org/glossary/product-owner/)

31
guide/arabic/algorithms/algorithm-design-patterns/behavioral-patterns/index.md
View File

@ -1,31 +0,0 @@
---
title: Behavioral patterns
localeTitle: الأنماط السلوكية
---
## الأنماط السلوكية
الأنماط التصميمية السلوكية هي أنماط التصميم التي تحدد مشاكل الاتصال الشائعة بين الأشياء وتحقق هذه الأنماط. من خلال القيام بذلك ، تزيد هذه الأنماط من المرونة في تنفيذ هذا الاتصال ، مما يجعل البرنامج أكثر موثوقية وسهل.
تتضمن أمثلة هذا النوع من أنماط التصميم:
1. **نمط سلسلة المسئولية** : تتم معالجة كائنات الأوامر أو تمريرها إلى كائنات أخرى بواسطة كائنات معالجة تحتوي على المنطق.
2. **نمط الأوامر** : تقوم كائنات الأوامر بتغليف إجراء ومعلماته.
3. **نمط المترجم** : تنفيذ لغة كمبيوتر متخصصة لحل مجموعة محددة من المشكلات بسرعة.
4. **نمط التكرار** : يتم استخدام المتكررات للوصول إلى عناصر كائن تجميعي بشكل تسلسلي دون تعريض التمثيل الأساسي الخاص به.
5. **نمط الوسيط** : يوفر واجهة موحدة لمجموعة من الواجهات في النظام الفرعي.
6. **نمط تذكار** : يوفر القدرة على استعادة كائن إلى حالته السابقة (التراجع).
7. **نمط كائن فارغ** : تم تصميمه ليكون بمثابة قيمة افتراضية للكائن.
8. **نمط** **الملاحظ** : الملقب P **ublish / اشتراك** أو **مستمع الحدث** . تسجيل كائنات لمراقبة حدث قد يتم رفعه بواسطة كائن آخر.
9. **نمط مرجعي ضعيف** : قم بإزالة مراقب من شخص يمكن ملاحظته.
10. **مكدس البروتوكول** : يتم التعامل مع الاتصالات بواسطة طبقات متعددة ، والتي تشكل تسلسل هرمي للتغليف.
11. **نمط** المهمة المجدولة: من المقرر أن يتم تنفيذ مهمة في فترة زمنية محددة أو على مدار الساعة (تستخدم في الحوسبة في الوقت الفعلي).
12. **نمط زائر أحادي الخدمة** : يمكنك تحسين تنفيذ الزائر المخصص ، واستخدامه مرة واحدة فقط ، ثم حذفه.
13. **نمط المواصفة** : منطق عمل متجانس بطريقة بوليانية.
14. **نمط الحالة** : طريقة نظيفة لكائن لتغيير نوعه بشكل جزئي في وقت التشغيل.
15. **نمط الإستراتيجية** : يمكن اختيار الخوارزميات بسرعة.
16. **نمط أسلوب القالب** : يصف الهيكل العظمي للبرنامج.
17. **نمط الزائر** : طريقة لفصل خوارزمية من كائن ما.
### مصادر
[https://en.wikipedia.org/wiki/Behavioral\_pattern](https://en.wikipedia.org/wiki/Behavioral_pattern)

21
guide/arabic/algorithms/algorithm-design-patterns/creational-patterns/index.md
View File

@ -1,21 +0,0 @@
---
title: Creational patterns
localeTitle: الأنماط الإبداعية
---
## الأنماط الإبداعية
أنماط التصميم الإبداعية هي أنماط التصميم التي تتعامل مع آليات إنشاء الكائنات ، وتحاول إنشاء كائنات بطريقة تتناسب مع الموقف. يمكن أن يؤدي الشكل الأساسي لإنشاء الكائنات إلى مشاكل في التصميم أو في تعقيد إضافي للتصميم. تعمل أنماط التصميم الإبداعية على حل هذه المشكلة عن طريق التحكم في إنشاء هذا الكائن بطريقة أو بأخرى.
تتكون أنماط التصميم الإبداعي من فكرتين مهيمنتين. واحد هو تغليف المعرفة حول الفئات الملموسة التي يستخدمها النظام. آخر هو إخفاء كيف يتم إنشاء حالات من هذه الفئات الملموسة والجمع بينها.
هناك خمسة أنماط تصميم معروفة هي أجزاء من الأنماط الإبداعية:
1. **نمط المصنع المجرد** ، الذي يوفر واجهة لإنشاء كائنات مرتبطة أو مرتبطة بدون تحديد فئات الخرسانة الخاصة بالأشياء.
2. **نمط البناء** ، الذي يفصل بناء كائن معقد من تمثيله بحيث يمكن لعملية الإنشاء نفسها إنشاء تمثيلات مختلفة.
3. **نمط طريقة المصنع** ، والذي يسمح للطبقة بتأجيل إنشاء الكتل إلى الفئات الفرعية.
4. **نمط النموذج** ، الذي يحدد نوع الكائن الذي يتم إنشاؤه باستخدام مثيل نموذجي ، ويخلق كائنات جديدة عن طريق استنساخ هذا النموذج الأولي.
5. **نمط Singleton** ، الذي يضمن أن يكون للفئة مثيل واحد فقط ، ويوفر نقطة وصول عالمية إليه.
### مصادر
1. [جاما ، إريك ؛ هيلم ، ريتشارد. جونسون ، رالف. Vlissides، John (1995). أنماط التصميم. ماساتشوستس: أديسون ويسلي. ص. 81. ISBN 978-0-201-63361-0. استرجع 2015-05-22.](http://www.pearsoned.co.uk/bookshop/detail.asp?item=171742)

27
guide/arabic/algorithms/algorithm-design-patterns/index.md
View File

@ -1,27 +0,0 @@
---
title: Algorithm Design Patterns
localeTitle: أنماط تصميم الخوارزمية
---
## أنماط تصميم الخوارزمية
في هندسة البرمجيات ، يعتبر نمط التصميم حلاً متكرراً عام لمشكلة شائعة الحدوث في تصميم البرامج. نمط التصميم ليس تصميمًا نهائيًا يمكن تحويله مباشرةً إلى شفرة. هو وصف أو قالب لكيفية حل مشكلة يمكن استخدامها في العديد من المواقف المختلفة.
يمكن لأنماط التصميم تسريع عملية التطوير من خلال تقديم نماذج تطوير مجربة ومثبتة.
تنقسم هذه الأنماط إلى ثلاث فئات رئيسية:
### الأنماط الإبداعية
هذه هي أنماط التصميم التي تتعامل مع آليات إنشاء الكائنات ، وتحاول إنشاء كائنات بطريقة تتناسب مع الموقف. يمكن أن يؤدي الشكل الأساسي لإنشاء الكائنات إلى مشاكل في التصميم أو في تعقيد إضافي للتصميم. تعمل أنماط التصميم الإبداعية على حل هذه المشكلة عن طريق التحكم في إنشاء هذا الكائن بطريقة أو بأخرى.
### الأنماط الهيكلية
هذه هي أنماط التصميم التي تسهل التصميم من خلال تحديد طريقة بسيطة لتحقيق العلاقات بين الكيانات.
### الأنماط السلوكية
هذه هي أنماط التصميم التي تحدد أنماط الاتصال الشائعة بين الكائنات وتحقيق هذه الأنماط. من خلال القيام بذلك ، تزيد هذه الأنماط من المرونة في تنفيذ هذا الاتصال.
#### معلومات اكثر:
[أنماط التصميم - ويكيبيديا](https://en.wikipedia.org/wiki/Design_Patterns)

58
guide/arabic/algorithms/algorithm-design-patterns/structual-patterns/index.md
View File

@ -1,58 +0,0 @@
---
title: Structural patterns
localeTitle: الأنماط الهيكلية
---
## الأنماط الهيكلية
.في هندسة البرمجيات ، أنماط التصميم الإنشائية هي أنماط تصميم تسهل التصميم من خلال تحديد طريقة بسيطة لتحقيق العلاقات بين الكيانات
: أمثلة على الأنماط الهيكلية تشمل
**'adapts' : نمط المحول** •
.يحول واجهة واحدة لفئة معينة/ما إلى واجهة يتوقعها العميل
**محول خط الأنابيب** •
.استخدام/استعمال محولات متعددة لأغراض التصحيح
**نمط واجهة التحديث/نمط الواجهة التحديثية** •
.محول يستخدم كواجهة جديدة لفئات متعددة في نفس الوقت
**نمط التجميع** •
.نسخة من النمط المركب مع طرق لتجميع الأطفال
**نمط الجسر** •
.يفصل التجريد من تنفيده بحيث يمكن أن يختلف الاثنين بشكل مستقل
**حجر القبر/الضريح** •
.وسيط 'البحث' يحتوي على الموقع الحقيقي للشيئ
**النمط المركب** •
.شجرة الأشياء (على شكل هيكل شجرة) حيث أن لكل شيئ نفس الواجهة
**نمط الديكور/التصميم**
.إضافة وظائف إضافية إلى فئة ما في وقت التشغيل حيث يؤدي التصنيف الفرعي إلى زيادة هائلة للفئات الجديدة
**Framework المعروف أيضا باسم نمط التوسع** •
.يخفي التعليمات البرمجية المعقدة خلف واجهة بسيطة
**نمط الواجهة** •
.ينشأ واجهة مبسطة لواجهة موجودة مسبقا لتسهيل الاستخدام بالنسبة للمهام الشائعة
**Flyweight نمط** •
.كمية كبيرة من الأشياء تشترك خصائص مشتركة لتوفير المساحة
**نمط العلامة** •
.واجهة فارغة لربط البيانات الوصفية بفئة ما
**الأنابيب والمرشحات** •
.سلسلة من العمليات حيث يكون ناتج كل عملية هو مدخلات المرحلة التالية
**مؤشر غامض/معتم/مبهم** •
.مؤشر إلى نوع غير معلن أو خاص ، لإخفاء تفاصيل التنفيذ
**نمط الوكيل** •
.فئة تعمل كواجهة لشيء آخر
### المصدر
[https://en.wikipedia.org/wiki/Structural\_pattern](https://en.wikipedia.org/wiki/Structural_pattern)

92
guide/arabic/algorithms/algorithm-performance/index.md
View File

@ -1,92 +0,0 @@
---
title: Algorithm Performance
localeTitle: أداء الخوارزمية
---
في الرياضيات ، يعتبر التدرج الكبير O رمزية تستخدم لوصف ومقارنة _السلوك المحدد_ لوظيفة ما.
السلوك المحدود للوظيفة هو كيفية تصرف الدالة لأنها تميل إلى قيمة معينة وفي التدوين الكبير ، عادةً ما تكون في اتجاه الاتجاهات نحو اللانهاية.
باختصار ، يستخدم الترميز الكبير O لوصف نمو أو انخفاض وظيفة ، عادةً فيما يتعلق بوظيفة أخرى.
في تصميم الخوارزمية ، نستخدم عادةً تدوينًا كبيرًا لأننا نستطيع أن نرى كيف تعمل الخوارزمية السيئة أو الجيدة في أسوأ وضع. ولكن ضع في اعتبارك أنه ليس دائمًا الحالة نظرًا لأن الحالة الأسوأ قد تكون نادرة جدًا وفي هذه الحالات نحسب متوسط ​​الحالة. في الوقت الراهن لئلا تفريغ كبير O- التأويل.
في الرياضيات ، يعتبر التدرج الكبير O رمزية تستخدم لوصف ومقارنة _السلوك المحدد_ لوظيفة ما.
السلوك المحدود للوظيفة هو كيفية تصرف الدالة لأنها تتجه نحو قيمة معينة وفي التدوين الكبير ، عادة ما تكون في الاتجاه نحو اللانهاية.
باختصار ، يستخدم الترميز الكبير O لوصف نمو أو انخفاض وظيفة ، عادةً فيما يتعلق بوظيفة أخرى.
ملاحظة: x ^ 2 يساوي x \* x أو 'x-squared'\]
على سبيل المثال ، نقول إن x = O (x ^ 2) لكل x> 1 أو بمعنى آخر ، x ^ 2 هو الحد الأعلى على x وبالتالي فإنه ينمو بشكل أسرع.
يمكن استبدال رمز المطالبة مثل x = O (x ^ 2) لجميع x> _n_ بـ x <= x ^ 2 لجميع x> _n_ حيث _n_ هو أدنى رقم يفي بالمطالبة ، في هذه الحالة 1.
على نحو فعال ، نقول أن الدالة f (x) التي تمثل O (g (x)) تنمو أبطأ من g (x).
بشكل مقارن ، في علم الحاسوب وتطوير البرمجيات ، يمكننا استخدام التدوين الكبير O من أجل وصف كفاءة الخوارزميات عبر تعقيدها الزمني والفضائي.
يشير **تعقيد الفضاء** لخوارزمية إلى أثر ذاكرتها فيما يتعلق بحجم الإدخال.
على وجه التحديد عند استخدام تدوين كبير O ، فإننا نوضح كفاءة الخوارزمية فيما يتعلق بمدخلات: _n_ ، عادة عندما يقترب _n من_ اللانهاية.
عند فحص الخوارزميات ، نرغب عمومًا في تقليل وقت وتعقيد المساحة. تعقيد زمن o (1) يدل على الوقت الثابت.
من خلال مقارنة وتحليل الخوارزميات نحن قادرون على إنشاء تطبيقات أكثر كفاءة.
لأداء الخوارزمية لدينا عاملين رئيسيين:
* **الوقت** : نحتاج إلى معرفة مقدار الوقت المستغرق لتشغيل خوارزمية لبياناتنا وكيفية نموها حسب حجم البيانات (أو في بعض الحالات عوامل أخرى مثل عدد الأرقام وغيرها).
* **الفضاء** : ذاكرتنا مهيبة لذلك علينا أن نعرف مقدار المساحة الخالية التي نحتاجها لهذه الخوارزمية ، ومثل الوقت نحتاج إلى أن نكون قادرين على تتبع نموها.
تستخدم الترميزات الثلاث التالية في معظمها لتمثيل تعقيد خوارزميات الوقت:
1. **Θ التدوين** : تدوين ثيتا يقيّد الدوال من فوق وأسفل ، لذلك يعرّف السلوك الدقيق. يمكننا القول أن لدينا تدوين ثيتا عندما تكون الحالة الأسوأ وأفضل حالة هي نفسها.
> Θ (g (n)) = {f (n): توجد ثوابت موجبة c1 و c2 و n0 بحيث 0 = = c1 _g (n) <= f (n) <= c2_ g (n) لجميع n> = n0}
2. **Big O Notation** : يعرّف تدوين Big O الحد الأعلى لخوارزمية. على سبيل المثال ، يأخذ "فرز الإدراج" وقتًا خطيًا في أفضل الحالات والوقت التربيعي في أسوأ الحالات. يمكننا القول بأمان أن تعقيد وقت إدراج الإدراج هو _O_ ( _n ^ 2_ ).
> O (g (n)) = {f (n): توجد ثوابت موجبة c و n0 مثل 0 <= f (n) <= cg (n) لجميع n> = n0}
3. **Ω التدوين** : Ω الترميز يوفر الحد الأدنى من الخوارزمية. يظهر أسرع إجابة ممكنة لتلك الخوارزمية. > Ω (g (n)) = {f (n): توجد ثوابت موجبة c و n0 مثل 0 <= cg (n) <= f (n) لجميع n> = n0}.
## أمثلة
وكمثال على ذلك ، يمكننا فحص مدى تعقيد خوارزمية [\[الفقاعة التفسيرية\]](https://github.com/FreeCodeCamp/wiki/blob/master/Algorithms-Bubble-Sort.md#algorithm-bubble-sort) وتعبر عن ذلك باستخدام التدوين الكبير O.
#### فقاعة الفرز:
` // Function to implement bubble sort
void bubble_sort(int array<a href='http://bigocheatsheet.com/' target='_blank' rel='nofollow'>], int n)
{
// Here n is the number of elements in array
int temp;
for(int i = 0; i < n-1; i++)
{
// Last i elements are already in place
for(int j = 0; j < ni-1; j++)
{
if (array[j] > array[j+1])
{
// swap elements at index j and j+1
temp = array[j];
array[j] = array[j+1];
array[j+1] = temp;
}
}
}
}
`
النظر في هذا القانون، يمكننا أن نرى أنه في أفضل السيناريوهات حيث يتم فرز مجموعة بالفعل، فإن البرنامج يجعل فقط _ن_ والمقارنات كما لا مقايضة يحدث.
لذلك يمكننا القول أن أفضل تعقيد لحالة وقت نوع الفقاعة هو O ( _n_ ).
عند فحص سيناريو الحالة الأسوأ حيث تكون المصفوفة بترتيب عكسي ، سيؤدي التكرار الأول إلى إجراء مقارنات _n_ بينما سيتعين على التالي إجراء مقارنات _n_ - 1 وما إلى ذلك حتى يتم إجراء مقارنة واحدة فقط.
ومن ثم ، فإن التدوين الكبير O لهذه الحالة هو _n_ \* \[( _n_ - 1) / 2\] والتي = 0.5 _n_ ^ 2 - 0.5 _n_ = O ( _n_ ^ 2) حيث أن _n n_ ^ 2 يهيمن على الوظيفة التي تسمح لنا تجاهل المصطلح الآخر في الوظيفة.
يمكننا التأكد من هذا التحليل باستخدام \[هذه الورقة الغنائية سهلة الاستخدام الكبيرة التي تتميز بتعقيد وقت O كبير للعديد من هياكل البيانات والخوارزميات الشائعة الاستخدام
من الواضح جداً أنه في حالات الاستخدام الصغيرة ، قد يكون هذا التعقيد الزمني على ما يرام ، وعلى نحو كبير ، لا يكون فرز الفقاعات على نطاق واسع حلاً جيدًا للفرز.
هذه هي قوة التدوين الكبير: فهي تسمح للمطورين برؤية الاختناقات المحتملة لتطبيقهم بسهولة ، واتخاذ خطوات لجعلها أكثر قابلية للتوسع.
لمزيد من المعلومات حول سبب أهمية تحليلات big-O و algorithm ، قم بزيارة [تحدي الفيديو](https://www.freecodecamp.com/videos/big-o-notation-what-it-is-and-why-you-should-care) هذا!

52
guide/arabic/algorithms/avl-trees/index.md
View File

@ -1,52 +0,0 @@
---
title: AVL Trees
localeTitle: أشجار AVL
---
## أشجار AVL
شجرة AVL هي نوع فرعي من شجرة البحث الثنائية.
A BST هي بنية بيانات تتكون من العقد. لديها الضمانات التالية:
1. كل شجرة لديها عقدة جذرية (في الجزء العلوي).
2. العقدة الجذرية لديها صفر أو أكثر من العقد التابعة.
3. كل عقدة طفل لديها صفر أو أكثر العقد التابعة ، وهلم جرا.
4. كل عقدة لديها ما يصل إلى طفلين.
5. لكل عقدة ، يكون أحفادها الأيسر أقل من العقدة الحالية ، وهي أقل من الأسبقية الصحيحة.
تتمتع أشجار AVL بضمان إضافي:
6. لا يمكن أن يكون الفرق بين عمق الأشجار الفرعية اليمنى واليسرى أكثر من واحد. للحفاظ على هذا الضمان ، سيشمل تنفيذ AVL خوارزمية لإعادة توازن الشجرة عند إضافة عنصر إضافي من شأنه أن يخل بهذا الضمان.
تحتوي أشجار AVL على أسوأ حالة بحث ، وإدراج وحذف وقت O (log n).
### الدوران الأيمن
![شجرة AVL التناوب الصحيح](https://raw.githubusercontent.com/HebleV/valet_parking/master/images/avl_right_rotation.jpg)
### الدوران الأيسر
![شجرة AVL تناوب اليسار](https://raw.githubusercontent.com/HebleV/valet_parking/master/images/avl_left_rotation.jpg)
### عملية الإدراج AVL
ستفعل إدخال مشابه لإدراج شجرة البحث الثنائي العادي. بعد الإدراج ، يمكنك إصلاح خاصية AVL باستخدام عمليات الاستدارة إلى اليمين أو اليسار.
* إذا كان هناك اختلال في الطفل الأيسر من الشجرة الفرعية الصحيحة ، عندئذ تقوم بتدوير يسار يمين.
* إذا كان هناك اختلال في الطفل الأيسر من الشجرة الفرعية اليسرى ، فأنت تقوم بتناوب اليمين.
* إذا كان هناك اختلال في الطفل الصحيح من الشجرة الفرعية الصحيحة ، فأنت تقوم بتدوير اليسار.
* إذا كان هناك اختلال في الطفل الأيمن من الشجرة الفرعية اليسرى ، فأنت تقوم بتناوب اليمين إلى اليسار.
#### معلومات اكثر:
[يوتيوب - شجرة AVL](https://www.youtube.com/watch?v=7m94k2Qhg68)
شجرة AVL هي شجرة بحث ثنائية التوازن الذاتي. شجرة AVL هي شجرة بحث ثنائية لها الخصائص التالية: -> تختلف الأشجار الفرعية لكل عقدة في الارتفاع بمقدار واحد على الأكثر. -> كل شجرة فرعية هي شجرة AVL.
تتحقق شجرة AVL من ارتفاع اليسار والأشجار الفرعية اليمنى وتؤكد أن الفرق لا يزيد عن 1. ويسمى هذا الاختلاف "عامل التوازن". يكون طول شجرة AVL دائمًا O (Logn) حيث n هو عدد العقد في الشجرة.
دورات AVL للشجرة: -
في شجرة AVL ، بعد تنفيذ كل عملية مثل الإدراج والحذف ، نحتاج إلى التحقق من عامل التوازن لكل عقدة في الشجرة. إذا استوفت كل عقدة شرط عامل التوازن ، فإننا ننتهي من العملية وإلا يجب أن نجعلها متوازنة. نحن نستخدم عمليات الدوران لجعل الشجرة متوازنة عندما تصبح الشجرة غير متوازنة بسبب أي عملية.
تستخدم عمليات الدوران لجعل الشجرة متوازنة. يوجد أربع دورات ويتم تصنيفها إلى نوعين: -> دوران يسار واحد (دوران LL) في LL Rotation ، تقوم كل عقدة بنقل موضع واحد إلى اليسار من الموضع الحالي. -> دوران لليمين (دوران RR) في تناوب RR ، تقوم كل عقدة بنقل موضع واحد إلى اليمين من الموضع الحالي. -> دوران لليمين الأيسر (دورة LR) إن LR Rotation هو عبارة عن مجموعة من الدوران الأيسر المتبقي متبوعًا بالدوران اليميني المفرد. في LR Rotation ، تقوم كل عقدة أولاً بنقل موضع واحد إلى اليسار ثم موضع واحد إلى اليمين من الموضع الحالي. -> تناوب يمين يسار (دوران RL) يكون RL Rotation عبارة عن توليفة من الدوران الأيمن الفردي متبوعًا بالدوران الأيسر الوحيد. في RL Rotation ، تقوم كل عقدة أولاً بنقل موضع واحد إلى اليمين ثم موضع واحد إلى اليسار من الموضع الحالي.

15
guide/arabic/algorithms/b-trees/index.md
View File

@ -1,15 +0,0 @@
---
title: B Trees
localeTitle: الأشجار ب
---
## الأشجار ب
# المقدمة
B-Tree عبارة عن شجرة بحث ذات توازن ذاتي. في معظم أشجار البحث عن التوازن الذاتي (مثل AVL و Red Black Trees) ، من المفترض أن كل شيء في الذاكرة الرئيسية. لفهم استخدام B-Trees ، يجب أن نفكر في كمية هائلة من البيانات التي لا يمكن احتواؤها في الذاكرة الرئيسية. عندما يكون عدد المفاتيح مرتفعًا ، تتم قراءة البيانات من القرص في شكل كتل. وقت الوصول للقرص مرتفع جدًا مقارنة بوقت الوصول الرئيسي للذاكرة. الفكرة الرئيسية لاستخدام B-Trees هي تقليل عدد مرات الوصول إلى القرص. تتطلب معظم عمليات الشجرة (البحث أو الإدراج أو الحذف أو الحد الأقصى أو الحد الأدنى أو ..) إدخال O (h) للقرص حيث h ارتفاع الشجرة. ب شجرة هي شجرة الدهون. يتم الاحتفاظ ارتفاع B-Trees منخفضة عن طريق وضع أقصى مفاتيح ممكنة في عقدة B-Tree. بشكل عام ، يتم الاحتفاظ حجم عقدة B-Tree مساوية لحجم كتلة القرص. بما أن h منخفض لـ B-Tree ، فإن إجمالي الوصول للقرص لمعظم العمليات يتم تقليله بشكل كبير مقارنةً بأشجار Binary Search المتوازنة مثل AVL Tree و Red Black Tree و ..etc.
خصائص B-Tree: 1) جميع الأوراق في نفس المستوى. 2) يتم تعريف B-tree بالحد الأدنى من الدرجة 't'. تعتمد قيمة t على حجم كتلة القرص. 3) يجب أن تحتوي كل عقدة ما عدا الجذر على مفاتيح t-1 على الأقل. قد يحتوي الجذر على مفتاح 1 كحد أدنى. 4) جميع العقد (بما في ذلك الجذر) قد تحتوي على أكثر من 2t - 1 مفاتيح. 5) عدد أطفال العقدة يساوي عدد المفاتيح الموجودة به زائد 1. 6) يتم فرز جميع مفاتيح العقدة بترتيب متزايد. يحتوي الطفل بين مفتاحين k1 و k2 على كافة المفاتيح في النطاق من k1 و k2. 7) B-Tree ينمو وينكمش من الجذر الذي لا يشبه Binary Search Tree. أشجار البحث الثنائي تنمو إلى الأسفل وتقلص أيضًا من الهبوط. 8) مثل غيرها من الأشجار المتوازنة البحث ثنائي ، تعقيد الوقت للبحث ، وإدراج وحذف هو O (Logn).
بحث: يشبه البحث البحث في Binary Search Tree. دع المفتاح ليتم البحث عنه ك. نبدأ من الجذر والعكس بشكل متكرر. لكل عقدة non-leaf التي تمت زيارتها ، إذا كان للعقدة مفتاح ، فإننا نعيد العقدة ببساطة. وإلا فإننا نتراجع إلى الطفل المناسب (الطفل الذي هو قبل المفتاح الأول الأكبر) للعقدة. إذا وصلنا إلى عقدة أوراق ولم نعثر على k في عقدة الورقة ، نرجع NULL.
اجتياز: Traversal هو أيضا مماثل لاجتياز اجتياز شجرة ثنائية. نبدأ من الطفل الموجود في أقصى اليسار ، ونقوم بشكل متكرر بطباعة الطفل الموجود في أقصى اليسار ، ثم نكرر نفس العملية للأطفال والبقية المتبقين. في النهاية ، بشكل متكرر طباعة الطفل في أقصى اليمين.

55
guide/arabic/algorithms/backtracking-algorithms/index.md
View File

@ -1,55 +0,0 @@
---
title: Backtracking Algorithms
localeTitle: خوارزميات التراجع
---
# خوارزميات التراجع
التراجع هو خوارزمية عامة لإيجاد كل الحلول (أو بعض) لبعض المشاكل الحسابية ، ولا سيما مشاكل الرضا المقيدة ، التي تبني بشكل متزايد المرشحين للحلول ، وتتخلى عن كل مرشح جزئي _("backtracks")_ بمجرد أن يحدد أن المرشح لا يستطيع من المحتمل أن تكتمل إلى حل صالح.
### مثال على المشكلة (مشكلة جولة فارس)
_يتم وضع الفارس على أول كتلة من لوحة فارغة ، ويتحرك وفقا لقواعد لعبة الشطرنج ، يجب زيارة كل مربع مرة واحدة بالضبط._
\# # # # # اتبعها فارس لتغطية جميع الخلايا فيما يلي هو رقعة الشطرنج مع 8 × 8 خلايا. تشير الأرقام في الخلايا إلى تحريك عدد Knight. [![حل جولة فارس - عن طريق اويلر](https://upload.wikimedia.org/wikipedia/commons/d/df/Knights_tour_%28Euler%29.png)](https://commons.wikimedia.org/wiki/File:Knights_tour_(Euler).png)
### خوارزمية السذاجة لجولة نايت
تقوم Naive Algorithm بتوليد جميع الجولات واحدة تلو الأخرى والتحقق مما إذا كانت الجولة التي تم إنشاؤها تفي بالقيود.
```
while there are untried tours
{
generate the next tour
if this tour covers all squares
{
print this path;
}
}
```
### خوارزمية التراجع عن جولة نايت
فيما يلي خوارزمية Backtracking لمشكلة جولة Knight.
```
If all squares are visited
print the solution
Else
a) Add one of the next moves to solution vector and recursively
check if this move leads to a solution. (A Knight can make maximum
eight moves. We choose one of the 8 moves in this step).
b) If the move chosen in the above step doesn't lead to a solution
then remove this move from the solution vector and try other
alternative moves.
c) If none of the alternatives work then return false (Returning false
will remove the previously added item in recursion and if false is
returned by the initial call of recursion then "no solution exists" )
```
### معلومات اكثر
[ويكيبيديا](https://en.wikipedia.org/wiki/Backtracking)
[المهوسون 4 المهوسون](http://www.geeksforgeeks.org/backtracking-set-1-the-knights-tour-problem/)
[مقدمة مثيرة جدا للرجوع](https://www.hackerearth.com/practice/basic-programming/recursion/recursion-and-backtracking/tutorial/)

269
guide/arabic/algorithms/binary-search-trees/index.md
View File

@ -1,269 +0,0 @@
---
title: Binary Search Trees
localeTitle: أشجار البحث الثنائي
---
## أشجار البحث الثنائي
![شجرة البحث الثنائية](https://cdn-images-1.medium.com/max/1320/0*x5o1G1UpM1RfLpyx.png)
الشجرة هي بنية بيانات تتكون من عقد لها الخصائص التالية:
1. كل شجرة لديها عقدة جذرية (في الجزء العلوي) لديها بعض القيمة.
2. العقدة الجذرية لديها صفر أو أكثر من العقد التابعة.
3. كل عقدة طفل لديها صفر أو أكثر العقد التابعة ، وهلم جرا. هذا إنشاء شجرة فرعية في الشجرة. تحتوي كل عقدة على شجرة فرعية خاصة بها تتكون من أطفاله وأطفالهم ، إلخ. وهذا يعني أن كل عقدة بمفردها يمكن أن تكون شجرة.
تضيف شجرة البحث الثنائية (BST) هاتين الخاصيتين:
1. كل عقدة لديها حد أقصى يصل إلى طفلين.
2. لكل عقدة ، تكون قيم العقد المتسلسلة اليسرى أقل من عقدة العقدة الحالية ، والتي بدورها تكون أقل من العقد التناسلية الصحيحة (إن وجدت).
يتم إنشاء BST على فكرة خوارزمية [البحث الثنائي](https://guide.freecodecamp.org/algorithms/search-algorithms/binary-search) ، والتي تسمح [بالبحث](https://guide.freecodecamp.org/algorithms/search-algorithms/binary-search) السريع وإدخال وإزالة العقد. إن الطريقة التي يتم بها إعدادها تعني أنه في المتوسط ​​، تسمح كل مقارنة للعمليات بتخطي حوالي نصف الشجرة ، بحيث يستغرق كل بحث أو إدراج أو حذف وقتًا متناسبًا مع لوغاريتم عدد العناصر المخزنة في الشجرة ، `O(log n)` . ومع ذلك ، في بعض الأحيان يمكن أن يحدث أسوأ الحالات ، عندما تكون الشجرة غير متوازنة ويكون تعقيد الوقت هو `O(n)` لكل هذه الوظائف الثلاثة. هذا هو السبب في أشجار التوازن الذاتي (AVL ، أحمر أسود ، وما إلى ذلك) هي أكثر فعالية من BST الأساسية.
**أسوأ مثال على سيناريو الحالة:** يمكن أن يحدث هذا عند الاستمرار في إضافة العقد التي تكون _دائمًا_ أكبر من العقدة قبل (إنه الأصل) ، ويمكن أن يحدث نفس الشيء عندما تقوم دائمًا بإضافة العقد ذات القيم الأقل من أولياء أمورهم.
### العمليات الأساسية على BST
* إنشاء: ينشئ شجرة فارغة.
* إدراج: إدراج عقدة في الشجرة.
* بحث: يبحث عن عقدة في الشجرة.
* حذف: لحذف عقدة من الشجرة.
#### خلق
في البداية يتم إنشاء شجرة فارغة بدون أي عقد. تتم تهيئة المتغير / المعرف الذي يجب أن يشير إلى عقدة الجذر بقيمة `NULL` .
#### بحث
تبدأ دائمًا في البحث عن الشجرة في عقدة الجذر والنزول من هناك. يمكنك مقارنة البيانات في كل عقدة مع تلك التي تبحث عنها. إذا لم تتطابق العقدة المقارنة ، فإما أن تنتقل إلى الطفل الصحيح أو الطفل الأيسر ، والذي يعتمد على نتيجة المقارنة التالية: إذا كانت العقدة التي تبحث عنها أقل من تلك التي كنت تقارنها بها ، تنتقل إلى الطفل الأيسر ، وإلا (إذا كان أكبر) ، فانتقل إلى الطفل الصحيح. لماذا ا؟ نظرًا لأن BST منظم (وفقًا لتعريفه) ، فإن الطفل المناسب دائمًا يكون أكبر من الأصل وأن الطفل الأيسر يكون دائمًا أقل.
#### إدراج
انها تشبه الى حد بعيد وظيفة البحث. تبدأ مرة أخرى عند جذر الشجرة وتنزل بشكل متكرر ، حيث تبحث عن المكان المناسب لإدخال العقدة الجديدة ، بنفس الطريقة الموضحة في وظيفة البحث. إذا كانت العقدة ذات القيمة نفسها موجودة بالفعل في الشجرة ، يمكنك اختيار إما إدراج التكرار أم لا. بعض الأشجار تسمح بوجود نسخ مكررة ، والبعض الآخر لا يسمح بذلك. ذلك يعتمد على تنفيذ معين.
#### حذف
هناك 3 حالات يمكن أن تحدث عندما تحاول حذف عقدة. إذا كان لديه،
1. لا توجد شجرة فرعية (لا يوجد أطفال): هذا هو الأسهل. يمكنك ببساطة حذف العقدة ، دون أي إجراءات إضافية مطلوبة.
2. شجرة فرعية واحدة (طفل واحد): يجب عليك التأكد من أنه بعد حذف العقدة ، يتم توصيل الطفل التابع له إلى أصل العقدة المحذوفة.
3. صفحتان فرعيتان (طفلين): عليك البحث عن واستبدال العقدة التي تريد حذفها مع خلفها (العقدة الفاتنة في الشجرة الفرعية الصحيحة).
وقت تعقيد إنشاء الشجرة هو `O(1)` . يعتمد تعقيد وقت البحث عن عقدة أو إدخالها أو حذفها على ارتفاع الشجرة `h` ، لذا فإن الحالة الأسوأ هي `O(h)` .
#### سلف عقدة
يمكن وصف الإصدارات السابقة بأنها العقدة التي ستظهر قبل العقدة التي أنت فيها حاليًا. للعثور على سابق العقدة الحالية ، ابحث عن العقدة اليمنى الأكبر / الأكبر في الشجرة الفرعية اليسرى.
#### خلف العقدة
يمكن وصف الخلفاء على أنهم العقدة التي تأتي بعد العقدة التي أنت فيها حاليًا. للعثور على خليفة العقدة الحالية ، انظر إلى العقدة اليسرى / أقصى اليسار في الشجرة الفرعية اليمنى.
### أنواع خاصة من BT
* كومة
* شجرة حمراء سوداء
* B-شجرة
* شجرة سبلاي
* شجرة N-ary
* تري (شجرة الجذر)
### وقت التشغيل
**هيكل البيانات: صفيف**
* أسوأ حالة أداء: `O(log n)`
* أداء أفضل أداء: `O(1)`
* متوسط ​​الأداء: `O(log n)`
* أسوأ تعقيد في الفضاء: `O(1)`
حيث `n` هو عدد العقد في BST.
### تنفيذ BST
وإليك تعريفًا لعقدة BST التي تحتوي على بعض البيانات ، مع الإشارة إلى عقد الطفل اليمنى واليسرى.
```c
struct node {
int data;
struct node *leftChild;
struct node *rightChild;
};
```
#### عملية البحث
عندما يتم البحث عن عنصر ، ابدأ البحث من العقدة الجذرية. ثم إذا كانت البيانات أقل من قيمة المفتاح ، فابحث عن العنصر في الشجرة الفرعية اليسرى. خلاف ذلك ، ابحث عن العنصر في الشجرة الفرعية الصحيحة. اتبع نفس الخوارزمية لكل عقدة.
`struct node* search(int data){
struct node *current = root;
printf("Visiting elements: ");
while(current->data != data){
if(current != NULL) {
printf("%d ",current->data);
//go to left tree
if(current->data > data){
current = current->leftChild;
}//else go to right tree
else {
current = current->rightChild;
}
//not found
if(current == NULL){
return NULL;
}
}
}
return current;
}
`
#### أدخل العملية
عندما يتم إدراج عنصر ، حدد موقعه الصحيح أولاً. ابدأ البحث من العقدة الجذرية ، ثم إذا كانت البيانات أقل من قيمة المفتاح ، ابحث عن الموقع الفارغ في الشجرة الفرعية اليسرى وأدخل البيانات. وإلا ، فابحث عن الموقع الفارغ في الشجرة الفرعية الصحيحة وأدخل البيانات.
`void insert(int data) {
struct node *tempNode = (struct node*) malloc(sizeof(struct node));
struct node *current;
struct node *parent;
tempNode->data = data;
tempNode->leftChild = NULL;
tempNode->rightChild = NULL;
//if tree is empty
if(root == NULL) {
root = tempNode;
} else {
current = root;
parent = NULL;
while(1) {
parent = current;
//go to left of the tree
if(data < parent->data) {
current = current->leftChild;
//insert to the left
if(current == NULL) {
parent->leftChild = tempNode;
return;
}
}//go to right of the tree
else {
current = current->rightChild;
//insert to the right
if(current == NULL) {
parent->rightChild = tempNode;
return;
}
}
}
}
}
`
تتيح لنا أيضًا أشجار البحث الثنائي (BSTs) الوصول السريع إلى الأسلاف والخلفاء. يمكن وصف الإصدارات السابقة بأنها العقدة التي ستظهر قبل العقدة التي أنت فيها حاليًا.
* للعثور على سابق العقدة الحالية ، انظر إلى العقدة الموجودة في أقصى اليمين / أعلى ورقة في الشجرة الفرعية اليسرى. يمكن وصف الخلفاء على أنهم العقدة التي تأتي بعد العقدة التي أنت فيها حاليًا.
* للعثور على خليفة العقدة الحالية ، انظر إلى العقدة في أقصى اليسار / أصغر ورقة في الشجرة الفرعية اليمنى.
### دعونا ننظر في اثنين من الإجراءات التي تعمل على الأشجار.
بما أن الأشجار يتم تعريفها بشكل متكرر ، فمن الشائع جدًا كتابة الإجراءات الروتينية التي تعمل على أشجار متكررة.
على سبيل المثال ، إذا أردنا حساب ارتفاع الشجرة ، وهذا هو ارتفاع العقدة الجذرية ، يمكننا المضي قدمًا وبشكل متكرر ، من خلال الانتقال إلى الشجرة. لذلك يمكننا القول:
* على سبيل المثال ، إذا كان لدينا شجرة صفراء ، فإن ارتفاعها يبلغ 0.
* بخلاف ذلك ، نحن 1 زائد الحد الأقصى لشجرة الطفل اليسرى والشجرة الفرعية المناسبة.
* لذلك إذا نظرنا إلى ورقة على سبيل المثال ، فإن هذا الارتفاع سيكون 1 لأن ارتفاع الطفل الأيسر هو صفر ، هو 0 ، وارتفاع الطفل الأيمن صفر هو أيضا 0. لذا فإن الحد الأقصى لذلك هو 0 ، ثم 1 زائد 0.
#### خوارزمية الارتفاع (شجرة)
```
if tree = nil:
return 0
return 1 + Max(Height(tree.left),Height(tree.right))
```
#### هنا هو رمز في C ++
`int maxDepth(struct node* node)
{
if (node==NULL)
return 0;
else
{
int rDepth = maxDepth(node->right);
int lDepth = maxDepth(node->left);
if (lDepth > rDepth)
{
return(lDepth+1);
}
else
{
return(rDepth+1);
}
}
}
`
يمكن أن ننظر أيضا في حساب حجم الشجرة التي هي عدد العقد.
* مرة أخرى ، إذا كان لدينا شجرة لا شيء ، لدينا عقد الصفر.
* خلاف ذلك ، لدينا عدد العقد في الطفل الأيسر بالإضافة إلى 1 لأنفسنا بالإضافة إلى عدد العقد في الطفل الصحيح. 1 بالإضافة إلى حجم الشجرة اليسرى بالإضافة إلى حجم الشجرة الصحيحة.
#### خوارزمية الحجم (شجرة)
```
if tree = nil
return 0
return 1 + Size(tree.left) + Size(tree.right)
```
#### هنا هو رمز في C ++
```
int treeSize(struct node* node)
{
if (node==NULL)
return 0;
else
return 1+(treeSize(node->left) + treeSize(node->right));
}
```
### مقاطع الفيديو ذات الصلة على قناة YouTube freeCodeCamp
* [شجرة البحث الثنائية](https://youtu.be/5cU1ILGy6dM)
* [شجرة البحث الثنائية: عبور والطول](https://youtu.be/Aagf3RyK3Lw)
### فيما يلي الأنواع الشائعة من الأشجار الثنائية:
Full Binary Tree / Strict Binary Tree: شجرة ثنائية ممتلئة أو صارمة إذا كان لكل عقدة 0 أو 2 أطفال.
` 18
/ \
15 30
/ \ / \
40 50 100 40
`
في شجرة الثنائي الكاملة ، عدد العقد الورقية يساوي عدد العقد الداخلية زائد واحد.
إكمال Binary Tree: A Binary Tree اكتمال Binary Tree إذا تمت تعبئة كافة المستويات تمامًا باستثناء المستوى الأخير ، بينما يحتوي المستوى الأخير على كافة المفاتيح التي تم تركها قدر الإمكان
` 18
/ \
15 30
/ \ / \
40 50 100 40
/ \ /
8 7 9
`

43
guide/arabic/algorithms/boundary-fill/index.md
View File

@ -1,43 +0,0 @@
---
title: Boundary Fill
localeTitle: تعبئة الحدود
---
## تعبئة الحدود
التعبئة الحدودية هي الخوارزمية المستخدمة بشكل متكرر في رسومات الكمبيوتر لملء اللون المطلوب داخل مضلع مغلق له نفس الحدود اللون لجميع جوانبها.
يعتبر تنفيذ الخوارزمية الأكثر تقارباً دالة متكررة تستند إلى مكدس.
### العمل:
المشكلة بسيطة جدًا وتتبع عادةً الخطوات التالية:
1. خذ موضع نقطة البداية ولون الحدود.
2. قرّر منطقيًا تريد الذهاب في 4 اتجاهات (N، S، W، E) أو 8 اتجاهات (N، S، W، E، NW، NE، SW، SE).
3. اختر لون تعبئة.
4. السفر في تلك الاتجاهات.
5. إذا كانت وحدة البكسل التي تصل إليها ليست لون التعبئة أو لون الحدود ، فاستبدلها بلون التعبئة.
6. كرر 4 و 5 حتى تكون في كل مكان داخل الحدود.
### قيود معينة:
* يجب أن يكون اللون الحدودي هو نفسه لجميع حواف المضلع.
* يجب أن تكون نقطة البداية داخل المضلع.
### رمز مقتطف:
`void boundary_fill(int pos_x, int pos_y, int boundary_color, int fill_color)
{
current_color= getpixel(pos_x,pos_y); //get the color of the current pixel position
if( current_color!= boundary_color || currrent_color != fill_color) // if pixel not already filled or part of the boundary then
{
putpixel(pos_x,pos_y,fill_color); //change the color for this pixel to the desired fill_color
boundary_fill(pos_x + 1, pos_y,boundary_color,fill_color); // perform same function for the east pixel
boundary_fill(pos_x - 1, pos_y,boundary_color,fill_color); // perform same function for the west pixel
boundary_fill(pos_x, pos_y + 1,boundary_color,fill_color); // perform same function for the north pixel
boundary_fill(pos_x, pos_y - 1,boundary_color,fill_color); // perform same function for the south pixel
}
}
`
من الكود المعطى يمكنك أن ترى أنه لأي بكسل تصله ، عليك أولا التحقق مما إذا كان يمكن تغييره إلى fill\_color ومن ثم تقوم بذلك لجيرانه حتى يتم فحص كل البكسلات الموجودة داخل الحدود.

17
guide/arabic/algorithms/brute-force-algorithms/index.md
View File

@ -1,17 +0,0 @@
---
title: Brute Force Algorithms
localeTitle: خوارزميات القوة الغاشمة
---
## خوارزميات القوة الغاشمة
تشير خوارزميات Force Brute إلى نمط البرمجة الذي لا يتضمن أي اختصارات لتحسين الأداء ، ولكن بدلاً من ذلك يعتمد على قوة الحوسبة المحضة لتجربة كل الاحتمالات حتى يتم العثور على حل لمشكلة ما.
مثال تقليدي هو مشكلة بائع السفر (TSP). لنفترض أن أحد مندوبي المبيعات يحتاج إلى زيارة 10 مدن في جميع أنحاء البلاد. كيف يمكن للمرء تحديد الترتيب الذي ينبغي أن تزوره المدن بحيث يتم تصغير المسافة الإجمالية التي يتم قطعها؟ إن حل القوة الغاشمة هو ببساطة حساب المسافة الكلية لكل طريق ممكن ثم اختيار أقصر طريق. هذا ليس فعال بشكل خاص لأنه من الممكن القضاء على العديد من الطرق الممكنة من خلال الخوارزميات الذكية.
مثال آخر: كلمة المرور 5 أرقام ، في أسوأ الحالات السيناريو سيستغرق 10 5 محاولات للقضاء.
وقت تعقيد القوة الغاشمة هو **O (n \* m)** . لذا ، إذا كنا نبحث عن سلسلة من الأحرف "n" في سلسلة من الأحرف "m" باستخدام القوة الغاشمة ، فستأخذنا محاولات n \* m.
#### معلومات اكثر:
[ويكيبيديا](https://en.wikipedia.org/wiki/Brute-force_search)

33
guide/arabic/algorithms/divide-and-conquer-algorithms/index.md
View File

@ -1,33 +0,0 @@
---
title: Divide and Conquer Algorithms
localeTitle: خوارزمية تقسيم و قهر
---
## خوارزمية تقسيم و قهر
تقسيم وقهر (المقدمة) مثل Greedy و Dynamic Programming ، يعتبر Divide و Conquer نموذجًا خوارزميًا. تحل خوارزمية Divide و Conquer النموذجية مشكلة باستخدام الخطوات الثلاث التالية.
1. القسمة: كسر المشكلة المعطاة إلى مشاكل فرعية من نفس النوع.
2. قهر: حل متكرر هذه المشاكل الفرعية
3. الجمع بين: الجمع بين الإجابات بشكل مناسب
فيما يلي بعض الخوارزميات القياسية التي هي خوارزميات Divide و Conquer.
1) البحث الثنائي عبارة عن خوارزمية بحث. في كل خطوة ، تقارن الخوارزمية عنصر الإدخال x مع قيمة العنصر الأوسط في الصفيف. إذا تطابقت القيم ، فأرجع فهرس الوسط. وبخلاف ذلك ، إذا كانت x أقل من العنصر الأوسط ، فستتكرر الخوارزمية إلى الجانب الأيسر من العنصر الأوسط ، ثم تتكرر للجانب الأيمن من العنصر الأوسط.
2) Quicksort هو خوارزمية الفرز. تختار الخوارزمية عنصرًا محوريًا ، وتعيد ترتيب عناصر الصفيف بحيث تنتقل جميع العناصر الأصغر من العنصر المحوري المختار إلى الجانب الأيسر من المحور ، وتتحرك جميع العناصر الأكبر إلى الجانب الأيمن. وأخيرًا ، تقوم الخوارزمية بشكل متكرر بفرز subarrays على يمين ويسار العنصر المحوري.
3) دمج التصنيف هو أيضا خوارزمية الفرز. تقسم الخوارزمية المصفوفة إلى نصفين ، وتقوم بترتيبها بشكل متكرر ، ثم تقوم في النهاية بدمج النصفين اللذين تم فرزهما.
4) أقرب نقطة من النقاط المشكلة هي العثور على أقرب زوج من النقاط في مجموعة من النقاط في طائرة س ص. يمكن حل المشكلة في زمن O (n ^ 2) من خلال حساب المسافات لكل زوج من النقاط ومقارنة المسافات للعثور على الحد الأدنى. خوارزمية Divide و Conquer يحل المشكلة في وقت O (nLogn).
5) خوارزمية ستراسن هي خوارزمية فعالة لضرب المصفوفتين. هناك طريقة بسيطة لمضاعفة المصفوفتين تحتاج إلى 3 حلقات متداخلة وهي O (n ^ 3). تضاعف خوارزمية ستراسن مصفوفتين في زمن O (n ^ 2.8974).
6) خوارزمية تحويل Cooley – Tukey Fast Fourier Transform (FFT) هي أكثر الخوارزميات شيوعاً بالنسبة لـ FFT. هو عبارة عن خوارزمية divide و conquer التي تعمل في زمن O (nlogn).
7) كانت خوارزمية Karatsuba أول خوارزمية الضرب أسرع بشكل تقريبي من خوارزمية "المدرسة الصفية" التربيعية. يقلل من مضاعفة رقمين n-digit على الأكثر إلى n ^ 1.585 (وهو تقريب لسجل 3 في الأساس 2) من رقم واحد. وبالتالي فهو أسرع من الخوارزمية الكلاسيكية ، والتي تتطلب n ^ 2 منتجات من رقم واحد.
### Divide and Conquer (D & C) vs Dynamic Programming (DP)
يقسم النموذجان (D & C و DP) المشكلة المطروحة إلى مشاكل فرعية ويحلان المشكلات الفرعية. كيفية اختيار واحد منهم لمشكلة معينة؟ يجب استخدام Divide و Conquer عندما لا يتم تقييم المشاكل الثانوية نفسها عدة مرات. خلاف ذلك يجب استخدام البرمجة الديناميكية أو Memoization.
على سبيل المثال ، البحث الثنائي عبارة عن خوارزمية Divide و Conquer ، لم نقم أبدًا بتقييم نفس المشاكل الفرعية مرة أخرى. من ناحية أخرى ، من أجل حساب رقم فيبوناتشي nt ، ينبغي تفضيل البرمجة الديناميكية.

16
guide/arabic/algorithms/embarassingly-parallel-algorithms/index.md
View File

@ -1,16 +0,0 @@
---
title: Embarassingly Parallel Algorithms
localeTitle: الخوارزميات الموازية المحرجة
---
## الخوارزميات الموازية المحرجة
في البرمجة المتوازية ، هي خوارزمية متوازية محرجة لا تتطلب أي اتصال أو تبعية بين العمليات. على عكس مشكلات الحوسبة الموزعة التي تحتاج إلى الاتصال بين المهام - خاصةً فيما يتعلق بالنتائج الوسيطة ، من السهل تنفيذ الخوارزميات المتوازية المحرجة في مزارع الخوادم التي تفتقر إلى البنية التحتية الخاصة المستخدمة في مجموعة أجهزة كمبيوتر عملاقة حقيقية. نظرًا لطبيعة الخوارزميات المتوازية المحرجة ، فهي مناسبة تمامًا لمنصات التوزيع الكبيرة المستندة إلى الإنترنت ، ولا تعاني من التباطؤ المتوازي. عكس المشاكل المتوازية المحرجة هي مشاكل متسلسلة بطبيعتها ، والتي لا يمكن موازتها على الإطلاق. يمكن تلخيص الحالة المثالية للخوارزميات المتوازية المحرجة كما يلي:
* يتم تحديد جميع المشاكل الفرعية أو المهام قبل بدء الحسابات.
* يتم تخزين كافة الحلول الفرعية في مواقع الذاكرة المستقلة (المتغيرات ، عناصر الصفيف).
* وبالتالي ، فإن حساب الحلول الفرعية مستقل تمامًا.
* إذا تطلبت الحسابات بعض الاتصالات الأولية أو النهائية ، فإننا نسميها بشكل متوازي محرجًا.
قد يتساءل الكثيرون عن أصل مصطلح "محرج". في هذه الحالة ، لا يوجد شيء محرج يتعلق بالإحراج. في الواقع ، هذا يعني فرطًا كبيرًا - هنا نشير إلى مشاكل الموازاة التي هي "سهلة للغاية".
ومن الأمثلة الشائعة لمشكلة متوازية محرجة ، عرض الفيديو ثلاثي الأبعاد الذي يتم التعامل معه بواسطة وحدة معالجة الرسومات ، حيث يمكن التعامل مع كل إطار أو بيكسل دون الاعتماد المتبادل. بعض الأمثلة الأخرى هي بروتينات قابلة للطي يمكن أن تعمل على أي جهاز كمبيوتر مع كل آلة تقوم بعمل جزء صغير من العمل ، وتوليد كل المجموعات الفرعية ، والأرقام العشوائية ، ومحاكاة مونت كارلو.

11
guide/arabic/algorithms/evaluating-polynomials-direct-analysis/index.md
View File

@ -1,11 +0,0 @@
---
title: Evaluating Polynomials Direct Analysis
localeTitle: تقييم متعدد الحدود التحليل المباشر
---
## تقييم متعدد الحدود التحليل المباشر
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/evaluating-polynomials-direct-analysis/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

11
guide/arabic/algorithms/evaluating-polynomials-synthetic-division/index.md
View File

@ -1,11 +0,0 @@
---
title: Evaluating Polynomials Synthetic Division
localeTitle: تقييم متعدد polynomials قسم اصطناعي
---
## تقييم متعدد polynomials قسم اصطناعي
هذا هو كعب. [ساعد مجتمعنا على توسيعه](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/evaluating-polynomials-synthetic-division/index.md) .
[سيساعدك دليل النمط السريع هذا على ضمان قبول طلب السحب](https://github.com/freecodecamp/guides/blob/master/README.md) .
#### معلومات اكثر:

60
guide/arabic/algorithms/exponentiation/index.md
View File

@ -1,60 +0,0 @@
---
title: Exponentiation
localeTitle: الأسي
---
## الأسي
بعد كتابة رقمين صحيحين و n ، اكتب دالة لحساب ^ n.
#### الشفرة
نموذج حسابي: تقسيم وقهر.
```C
int power(int x, unsigned int y) {
if (y == 0)
return 1;
else if (y%2 == 0)
return power(x, y/2)*power(x, y/2);
else
return x*power(x, y/2)*power(x, y/2);
}
```
تعقيد الوقت: O (n) | تعقيد الفضاء: O (1)
#### الحل الأمثل: O (تسجيل الدخول)
```C
int power(int x, unsigned int y) {
int temp;
if( y == 0)
return 1;
temp = power(x, y/2);
if (y%2 == 0)
return temp*temp;
else
return x*temp*temp;
}
```
## الأسيوي وحدات
أعطيت ثلاثة أرقام x، y و p، compute (x ^ y)٪ p
`int power(int x, unsigned int y, int p) {
int res = 1;
x = x % p;
while (y > 0) {
if (y & 1)
res = (res*x) % p;
// y must be even now
y = y>>1;
x = (x*x) % p;
}
return res;
}
`
تعقيد الوقت: O (Log y).

97
guide/arabic/algorithms/flood-fill/index.md
View File

@ -1,97 +0,0 @@
---
title: Flood Fill Algorithm
localeTitle: خوارزمية تعبئة الفيضان
---
## خوارزمية تعبئة الفيضان
تعبئة الفيضان هي خوارزمية تستخدم بشكل أساسي لتحديد منطقة محددة مرتبطة بعقدة معينة في مصفوفة متعددة الأبعاد. أنه تشابه دقيق لأداة الجرافة في برامج الطلاء.
إن تنفيذ الخوارزمية الأكثر تقارباً هو وظيفة متكررة أساسها مكدس ، وهذا ما سنتحدث عنه التالى.
### كيف يعمل؟
المشكلة بسيطة جدًا وتتبع عادةً الخطوات التالية:
1. خذ موقف نقطة البداية.
2. قرّر منطقيًا تريد الذهاب في 4 اتجاهات ( **N، S، W، E** ) أو 8 اتجاهات ( **N، S، W، E، NW، NE، SW، SE** ).
3. اختر لونًا بديلًا ولونًا مستهدفًا.
4. السفر في تلك الاتجاهات.
5. إذا كان البلاط الذي تهبط عليه هدفًا ، فأعد إدخاله باللون المختار.
6. كرر 4 و 5 حتى تكون في كل مكان داخل الحدود.
لنأخذ الصفيف التالي كمثال:
![نص بديل](https://github.com/firealex2/Codingame/blob/master/small%208%20grid%20paintefffd.png)
المربع الأحمر هو نقطة البداية والمربعات الرمادية هي ما يسمى الجدران.
للحصول على مزيد من التفاصيل ، في ما يلي جزء من الشفرة يصف الوظيفة:
`int wall = -1;
void flood_fill(int pos_x, int pos_y, int target_color, int color)
{
if(a[pos_x][pos_y] == wall || a[pos_x][pos_y] == color) // if there is no wall or if i haven't been there
return; // already go back
if(a[pos_x][pos_y] != target_color) // if it's not color go back
return;
a[pos_x][pos_y] = color; // mark the point so that I know if I passed through it.
flood_fill(pos_x + 1, pos_y, color); // then i can either go south
flood_fill(pos_x - 1, pos_y, color); // or north
flood_fill(pos_x, pos_y + 1, color); // or east
flood_fill(pos_x, pos_y - 1, color); // or west
return;
}
`
كما رأينا أعلاه ، نقطة البداية (4،4). بعد استدعاء الدالة لإحداثيات البدء **x = 4** و **y = 4** ، يمكنني البدء في التحقق إذا لم يكن هناك جدار أو لون على الفور. إذا كان ذلك صحيحًا ، أضع علامة على المكان بـ **"لون"** واحد والبدء في التحقق من المربعات adiacent الأخرى.
الذهاب إلى الجنوب سنصل إلى النقطة (5،4) و تعمل الوظيفة مرة أخرى.
### مشكلة كسسيرسيسي
اعتبرت دائمًا أن حل مشكلة (أو أكثر) / ثانية باستخدام خوارزمية مستفادة حديثًا هو أفضل طريقة لفهمها بشكل كامل المفهوم.
إذن هنا واحد:
**بيان:**
في صفيف بدائي تحصل على عدد n من **"الجزر"** . حاول أن تجد أكبر مساحة في جزيرة و رقم الجزيرة المقابل. 0 علامات الماء وأي سائر آخر بين 1 و n يساوي مربع واحد من السطح المقابل لجزيرة س.
**إدخال**
* **ن** - عدد الجزر.
* **ل ، ج** - أبعاد المصفوفة.
* خطوط **ل** المقبلة، أرقام **ج** إعطاء **ل** صف من المصفوفة عشر.
**انتاج |**
* **أنا** - عدد الجزيرة مع أكبر مساحة.
* **أ** - منطقة **ط** 'الجزيرة عشر.
**مثلا:**
لديك المدخلات التالية:
`2 4 4
0 0 0 1
0 0 1 1
0 0 0 2
2 2 2 2
`
والتي سوف تحصل على الجزيرة لا. 2 كأكبر جزيرة بمساحة 5 مربعات.
### إشارة
المشكلة سهلة للغاية ، ولكن في ما يلي بعض التلميحات:
`1. Use the flood-fill algorithm whenever you encounter a new island.
2. As opposed to the sample code, you should go through the area of the island and not on the ocean (0 tiles).
`

124
guide/arabic/algorithms/graph-algorithms/breadth-first-search/index.md
View File

@ -1,124 +0,0 @@
---
title: Breadth First Search (BFS)
localeTitle: نطاق البحث الأول (BFS)
---
## نطاق البحث الأول (BFS)
Breadth First Search هي واحدة من أكثر خوارزميات الرسم البياني بسيطة. يقوم بتجاوز الرسم البياني عن طريق التحقق أولاً من العقدة الحالية ثم توسيعها بإضافة خلفائها إلى المستوى التالي. يتم تكرار العملية لجميع العقد في المستوى الحالي قبل الانتقال إلى المستوى التالي. إذا تم العثور على الحل يتوقف البحث.
### تصور
![](https://upload.wikimedia.org/wikipedia/commons/4/46/Animated_BFS.gif)
### تقييم
تعقيد الفضاء: O (n)
تعقيد حالة الوقت أسوأ: O (n)
اكتمال بحث First على مجموعة محدودة من العقد وأفضل إذا كانت تكلفة الانتقال من عقدة إلى أخرى ثابتة.
### رمز C ++ لتنفيذ BFS
`// Program to print BFS traversal from a given
// source vertex. BFS(int s) traverses vertices
// reachable from s.
#include<iostream>
#include <list>
using namespace std;
// This class represents a directed graph using
// adjacency list representation
class Graph
{
int V; // No. of vertices
// Pointer to an array containing adjacency
// lists
list<int> *adj;
public:
Graph(int V); // Constructor
// function to add an edge to graph
void addEdge(int v, int w);
// prints BFS traversal from a given source s
void BFS(int s);
};
Graph::Graph(int V)
{
this->V = V;
adj = new list<int>[V];
}
void Graph::addEdge(int v, int w)
{
adj[v].push_back(w); // Add w to v's list.
}
void Graph::BFS(int s)
{
// Mark all the vertices as not visited
bool *visited = new bool[V];
for(int i = 0; i < V; i++)
visited[i] = false;
// Create a queue for BFS
list<int> queue;
// Mark the current node as visited and enqueue it
visited[s] = true;
queue.push_back(s);
// 'i' will be used to get all adjacent
// vertices of a vertex
list<int>::iterator i;
while(!queue.empty())
{
// Dequeue a vertex from queue and print it
s = queue.front();
cout << s << " ";
queue.pop_front();
// Get all adjacent vertices of the dequeued
// vertex s. If a adjacent has not been visited,
// then mark it visited and enqueue it
for (i = adj[s].begin(); i != adj[s].end(); ++i)
{
if (!visited[*i])
{
visited[*i] = true;
queue.push_back(*i);
}
}
}
}
// Driver program to test methods of graph class
int main()
{
// Create a graph given in the above diagram
Graph g(4);
g.addEdge(0, 1);
g.addEdge(0, 2);
g.addEdge(1, 2);
g.addEdge(2, 0);
g.addEdge(2, 3);
g.addEdge(3, 3);
cout << "Following is Breadth First Traversal "
<< "(starting from vertex 2) \n";
g.BFS(2);
return 0;
}
`
#### معلومات اكثر:
[الرسوم البيانية](https://github.com/freecodecamp/guides/computer-science/data-structures/graphs/index.md)
[عمق البحث الأول (DFS)](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/graph-algorithms/depth-first-search/index.md)

106
guide/arabic/algorithms/graph-algorithms/depth-first-search/index.md
View File

@ -1,106 +0,0 @@
---
title: Depth First Search (DFS)
localeTitle: عمق البحث الأول (DFS)
---
## عمق البحث الأول (DFS)
يعد Depth First Search واحدًا من أكثر خوارزميات الرسم البياني بسيطة. إنها تعبر الرسم البياني عن طريق التحقق أولاً من العقدة الحالية ومن ثم الانتقال إلى أحد مساعديها لتكرار العملية. إذا لم يكن لدى العقدة الحالية أي اختبار للتحقق ، فإننا ننتقل إلى سابقه وتستمر العملية (بالانتقال إلى سواقة أخرى). إذا تم العثور على الحل يتوقف البحث.
### تصور
![](https://upload.wikimedia.org/wikipedia/commons/7/7f/Depth-First-Search.gif)
### التنفيذ (C ++ 14)
\`\` \`ج ++
# تتضمن
# تتضمن
# تتضمن
# تتضمن
استخدام اسم للمحطة؛
الرسم البياني للفئة { في التلفاز؛ // عدد القمم
`// pointer to a vector containing adjacency lists
vector < int > *adj;
`
عامة: الرسم البياني (كثافة العمليات) ؛ // البناء
``// function to add an edge to graph
void add_edge(int v, int w);
// prints dfs traversal from a given source `s`
void dfs();
void dfs_util(int s, vector < bool> &visited);
``
}؛
الرسم البياني :: Graph (int v) { هذا -> v = v؛ adj = new vector <int> \[v\]؛ }
void Graph :: add _edge (int u، int v) { adj \[u\] .الرجوع_ مرة أخرى (v)؛ // add v to u's list adj \[v\] .العودة _(v)؛ // add u to v's list (أزل هذا البيان إذا تم توجيه الرسم البياني!) } void Graph :: dfs () { // زار متجه - لتتبع العقد التي تمت زيارتها خلال DFS تمت زيارة vector <bool> (v، false)؛ // بمناسبة جميع العقد / الرؤوس كما لم تتم زيارته لـ (int i = 0؛ i <v؛ i ++) إذا (! زار \[أنا\]) dfs_ util (i، visited)؛ } // لاحظ استخدام استدعاء من قبل هنا! void Graph :: dfs\_util (int s، vector <bool> & visited) { // قم بتمييز العقدة / قمة الرأس الحالية كما تمت زيارتها زار \[ص\] = صحيح. // إخراجها إلى الإخراج القياسي (الشاشة) cout << s << ""؛
`// traverse its adjacency list and recursively call dfs_util for all of its neighbours!
// (only if the neighbour has not been visited yet!)
for(vector < int > :: iterator itr = adj[s].begin(); itr != adj[s].end(); itr++)
if(!visited[*itr])
dfs_util(*itr, visited);
`
}
انت مين() { // أنشئ رسمًا بيانيًا باستخدام طبقة الرسم البياني التي حددناها أعلاه الرسم البياني (4) ؛ g.add _edge (0، 1)؛ g.add_ edge (0، 2)؛ g.add _edge (1، 2)؛ g.add_ edge (2، 0)؛ g.add _edge (2، 3)؛ g.add_ edge (3، 3)؛
`cout << "Following is the Depth First Traversal of the provided graph"
<< "(starting from vertex 0): ";
g.dfs();
// output would be: 0 1 2 3
return 0;
`
}
```
### Evaluation
Space Complexity: O(n)
Worse Case Time Complexity: O(n)
Depth First Search is complete on a finite set of nodes. I works better on shallow trees.
### Implementation of DFS in C++
```
ج ++
# تتضمن
# تتضمن
# تتضمن
استخدام اسم للمحطة؛
الرسم البياني للهيكل { في التلفاز؛ bool \* _adj؛ عامة: الرسم البياني (كثافة العمليات vcount) ؛ void addEdge (int u، int v)؛ void deleteEdge (int u، int v)؛ قوه موجهة_ _DFS (int s) ؛ void DFSUtil (int s، vector_ _وDFS، ناقلات_ _وزار)؛ }؛ Graph :: Graph (int vcount) { هذا-> v = vcount ؛ this-> adj = new bool_ \[vcount\]؛ ل (int i = 0؛ i
void Graph :: addEdge (int u، int w) { هذا-> صفة \[ش\] \[ث\] = صحيح. هذا-> صفة \[ث\] \[ش\] = صحيح. }
void Graph :: deleteEdge (int u، int w) { هذا-> صفة \[ش\] \[ث\] = كاذبة؛ هذا-> صفة \[ث\] \[ش\] = كاذبة؛ }
void Graph :: DFSUtil (int s، vector & DFS ، ناقلات وزار) { زار \[ق\] = صحيح. dfs.push\_back (ق)؛ ل (int i = 0؛ i الخامس، وأنا ++) { if (this-> adj \[s\] \[i\] == true && visited \[i\] == false) DFSUtil (ط، DFS، زار)؛ } }
قوه موجهة الرسم البياني :: DFS (int s) { قوه موجهة زار (هذا-> الخامس)؛ قوه موجهة DFS. DFSUtil (ق، DFS، زار)؛ العودة dfs؛ } \`\` \`
#### معلومات اكثر:
[الرسوم البيانية](https://github.com/freecodecamp/guides/computer-science/data-structures/graphs/index.md)
[نطاق البحث الأول (BFS)](https://github.com/freecodecamp/guides/tree/master/src/pages/algorithms/graph-algorithms/breadth-first-search/index.md)
[عمق البحث الأول (DFS) - ويكيبيديا](https://en.wikipedia.org/wiki/Depth-first_search)

93
guide/arabic/algorithms/graph-algorithms/dijkstra/index.md
View File

@ -1,93 +0,0 @@
---
title: Dijkstra's Algorithm
localeTitle: خوارزمية Dijkstra
---
# خوارزمية Dijkstra
خوارزمية Dijkstra هي خوارزمية رسم بياني قدمها EW Dijkstra. يجد مسار أقصر مصدر مفرد في الرسم البياني مع حواف غير سالبة. (لماذا؟)
نقوم بإنشاء صفيفين: زيارة والمسافة ، والتي تسجل ما إذا كان يتم زيارة قمة الرأس وما هي المسافة الدنيا من قمة الرأس على التوالي. يتم تعيين المصفوفة التي تمت زيارتها في البداية على أنها خاطئة والمسافة باعتبارها لانهائية.
نبدأ من قمة الرأس المصدر. دع الذروة الحالية تكون u والقرناصات المتاخمة لها v الآن لكل v الذي يكون متجها إلى u ، يتم تحديث المسافة إذا لم يتم زيارتها من قبل والمسافة من u أقل من المسافة الحالية. ثم نختار قمة الرأس التالية بأقل مسافة والتي لم يتم زيارتها.
غالبًا ما يتم استخدام قائمة انتظار الأولوية للوفاء بهذا المطلب الأخير في أقل وقت ممكن. فيما يلي تنفيذ نفس الفكرة باستخدام طابور الأولوية في Java.
`import java.util.*;
public class Dijkstra {
class Graph {
LinkedList<Pair<Integer>> adj[];
int n; // Number of vertices.
Graph(int n) {
this.n = n;
adj = new LinkedList[n];
for(int i = 0;i<n;i++) adj[i] = new LinkedList<>();
}
// add a directed edge between vertices a and b with cost as weight
public void addEdgeDirected(int a, int b, int cost) {
adj[a].add(new Pair(b, cost));
}
public void addEdgeUndirected(int a, int b, int cost) {
addEdgeDirected(a, b, cost);
addEdgeDirected(b, a, cost);
}
}
class Pair<E> {
E first;
E second;
Pair(E f, E s) {
first = f;
second = s;
}
}
// Comparator to sort Pairs in Priority Queue
class PairComparator implements Comparator<Pair<Integer>> {
public int compare(Pair<Integer> a, Pair<Integer> b) {
return a.second - b.second;
}
}
// Calculates shortest path to each vertex from source and returns the distance
public int[] dijkstra(Graph g, int src) {
int distance[] = new int[gn]; // shortest distance of each vertex from src
boolean visited[] = new boolean[gn]; // vertex is visited or not
Arrays.fill(distance, Integer.MAX_VALUE);
Arrays.fill(visited, false);
PriorityQueue<Pair<Integer>> pq = new PriorityQueue<>(100, new PairComparator());
pq.add(new Pair<Integer>(src, 0));
distance[src] = 0;
while(!pq.isEmpty()) {
Pair<Integer> x = pq.remove(); // Extract vertex with shortest distance from src
int u = x.first;
visited[u] = true;
Iterator<Pair<Integer>> iter = g.adj[u].listIterator();
// Iterate over neighbours of u and update their distances
while(iter.hasNext()) {
Pair<Integer> y = iter.next();
int v = y.first;
int weight = y.second;
// Check if vertex v is not visited
// If new path through u offers less cost then update distance array and add to pq
if(!visited[v] && distance[u]+weight<distance[v]) {
distance[v] = distance[u]+weight;
pq.add(new Pair(v, distance[v]));
}
}
}
return distance;
}
public static void main(String args[]) {
Dijkstra d = new Dijkstra();
Dijkstra.Graph g = d.new Graph(4);
g.addEdgeUndirected(0, 1, 2);
g.addEdgeUndirected(1, 2, 1);
g.addEdgeUndirected(0, 3, 6);
g.addEdgeUndirected(2, 3, 1);
g.addEdgeUndirected(1, 3, 3);
int dist[] = d.dijkstra(g, 0);
System.out.println(Arrays.toString(dist));
}
}
`

Some files were not shown because too many files have changed in this diff Show More