مستخدم:أنور الغليلات/ملعب

تطوير البرمجيات رشيق:

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

اسلاف

أساليب تطوير البرمجيات الإضافية تتبع مرة أخرى إلى عام 1957. [3] وفي عام 1974، كتب EA ادموندز ورقة التي أدخلت عملية تطوير البرمجيات على التكيف. [4] [5] وفي نفس الوقت وبشكل مستقل، وقد وضعت نفس الأساليب ونشرت صحيفة نيويورك الهاتف مركز الشركة تطوير النظم تحت إشراف دان Gielan. في أوائل 1970s، بدأ توم Gilb نشر مفاهيم إدارة المشاريع التطورية (EVO)، والتي تطورت لتصبح هندسة تنافسية. [6] وخلال منتصف إلى أواخر 1970s، حاضر Gielan على نطاق واسع في جميع أنحاء الولايات المتحدة على هذه المنهجية، ممارساتها، والاستفادة من نتائجه.

مجموعة من الأساليب خفيفة تطوير البرمجيات تطورت في منتصف 1990s في رد فعل على الطرق الموجهة شلال الوزن الثقيل ينظر النقاد الذي دعا تنظيم صارم، الصرامة، وتمكن الصغير؛ . على الرغم من أن بعض أنصار هذه الأساليب خفيفة الوزن ادعت أنهم ببساطة العودة إلى الممارسات البرمجيات السابقة [3] وشملت هذه الأساليب خفيفة الوزن: من عام 1994، عملية موحدة والأنظمة الديناميكية طريقة وضع (DSDM)؛ من عام 1995، زحاما كثيفا. من عام 1996، اضحة وضوح الشمس والمتطرفة برمجة (ويعرف أيضا باسم "إكس بي")؛ ومنذ عام 1997، وتطوير البرمجيات على التكيف وميزة يحركها التنمية. على الرغم من أن هذه نشأت قبل صدور البيان رشيق في عام 2001، والآن يشار إليهم مجتمعين إلى أساليب رشيقة الحال؛ [7]، وغالبا ما يختصر بشكل عام بأنها رشيق، مع رأسمال A، على الرغم من أن هذا تدريجيا تصبح مهملة

التطورات

في وقت لاحق، كين Schwaber مع الآخرين أسس التحالف سكروم وخلق برامج الماجستير معتمد سكروم ومشتقاته. غادر Schwaber التحالف سكروم في خريف عام 2009، وأسس Scrum.org.

في عام 2005، مجموعة يرأسها اليستير كوكبرن وجيم هايسميث كتب إضافة لمبادئ إدارة المشاريع، وإعلان التكافل، [12] لتوجيه إدارة مشروع البرمجيات وفقا لأساليب تطوير البرمجيات رشيقة.

في عام 2009، وهي حركة بقيادة روبرت C مارتن كتب امتدادا لمبادئ تطوير البرمجيات، والبرمجيات الحرفية البيان، لتوجيه تطوير البرمجيات رشيقة وفقا لقواعد السلوك المهني وإتقان.

في عام 2011 تحالف رشيق الأصلي [13] إنشاء دليل رشيق الممارسات، وهي تتطور خلاصة مفتوحة المصدر للتعريفات تعمل من ممارسات رشيقة، والمصطلحات، والعناصر، جنبا إلى جنب مع تفسيرات والمبادئ التوجيهية خبرة من المجتمع في جميع أنحاء العالم من الممارسين رشيقة .

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

التكرارية وتدريجية وتطورية

أساليب التطور الأكثر نشاطا كسر المهام إلى زيادات صغيرة مع الحد الأدنى من التخطيط ولا تنطوي مباشرة التخطيط على المدى الطويل. التكرار هي فترات زمنية قصيرة (timeboxes) التي تستمر عادة من أسبوع إلى أربعة أسابيع. كل التكرار ينطوي على فريق متعدد الوظائف يعمل في جميع وظائف هي: التخطيط وتحليل الاحتياجات، وتصميم، الترميز، واختبار وحدة، واختبار القبول. في نهاية التكرار ويتجلى منتج العمل لأصحاب المصلحة. هذا يقلل من مخاطر الإصابة بالسرطان ويسمح المشروع على التكيف مع التغيرات بسرعة. التكرار قد لا يضيف وظائف كافية لتبرير إطلاق السوق، ولكن الهدف هو أن يكون إطلاق المتاحة (مع الحد الأدنى من البق) في نهاية كل تكرار. قد تكون هناك حاجة [15] التكرار متعددة للافراج عن المنتج أو الميزات الجديدة

كفاءة وجها لوجه الاتصالات

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

في مجال تطوير البرمجيات رشيقة، والمبرد المعلومات هو العرض المادي (كبير عادة) مكان بارز في المكتب، حيث المارة يمكن أن نرى ذلك. ويعرض ملخص ما يصل إلى تاريخ وضع مشروع برنامج أو منتج آخر. [17] [18] وقد أطلق على هذا الاسم من قبل اليستير كوكبرن، ووصف في تقريره لعام 2002 كتاب رشيق تطوير البرمجيات. [18] ضوء البناء مؤشر يمكن أن تستخدم لإبلاغ فريق حول الوضع الحالي لمشروعهم.

التركيز على الجودة

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

الفلسفه

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

التكيف مقابل التنبؤية

توجد طرق التطوير في سلسلة متصلة من التكيف مع التنبؤية. [21] الأساليب رشيق تقع على الجانب التكيف من هذه السلسلة. مفتاح واحد من أساليب تطوير التكيف هو نهج "رولينج الموجة" للتخطيط الجدول الزمني، الذي يحدد معالم لكنه يترك مرونة في مسار للوصول إليها، ويسمح أيضا لتلك المراحل نفسها للتغيير. وتركز [22] الأساليب التكيفية على التكيف بسرعة ل تغيير الحقائق. عندما احتياجات تغيير المشروع، فريق التكيف يتغير أيضا. فريق التكيف لديه صعوبة تصف بالضبط ما سيحدث في المستقبل. وأبعد من التاريخ، وأكثر غامض طريقة التكيف هو حول ما سيحدث في ذلك التاريخ. فريق التكيف لا يستطيع أن يقدم تقريرا بالضبط ما المهام التي ستفعل الأسبوع المقبل، ولكن فقط التي يتميز انهم يخططون للشهر المقبل. وعندما سئل عن بيان ستة أشهر من الآن، وفريق التكيف قد تكون قادرة على تقديم تقرير فقط بيان مهمة من أجل إطلاق سراح، أو بيان القيمة المتوقعة مقابل التكلفة.

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

تكراريه مقابل الشلال

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

لأن يتم اختبار في كل التكرار، التي تطور قطعة صغيرة من البرمجيات للمستخدمين في كثير من الأحيان يمكن استخدام تلك القطع الجديدة من البرمجيات والتحقق من صحة القيمة.

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

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

بسبب أسلوب التكرار قصيرة من تطوير البرمجيات رشيقة، كما أن لديها صلات قوية مع مفهوم بدء التشغيل العجاف.

كود مقابل وثائق

في رسالة الى IEEE الكمبيوتر، أعرب ستيفن راكيتين السخرية حول تطوير رشيقة، ووصفه بأنه "محاولة أخرى لتقويض انضباط هندسة البرمجيات" وترجمة "البرامج على وثائق شاملة العمل" بأنها "نريد لقضاء كل وقتنا الترميز. حفظ والمبرمجين الحقيقي لا يكتب الوثائق. "[25]

والمتنازع عليها ذلك عن طريق دعاة تطوير البرمجيات رشيقة، الذين يعلنون أن المطورين يجب إرسال الوثائق إذا كان هذا هو أفضل وسيلة لتحقيق الأهداف ذات الصلة، إلا أن هناك طرق كثير من الأحيان أفضل لتحقيق تلك الأهداف من كتابة وثائق ثابتة. [26] الدول سكوت من Ambler وينبغي أن يكون ذلك وثائق "فقط جيد وهو ما يكفي بالكاد" (JBGE)، [27] أن الوثائق أكثر من اللازم أو شاملة سوف تسبب عادة النفايات، والمطورين ونادرا ما يثق ثائق مفصلة لانها عادة ما تكون متزامنة مع رمز، [26] في حين أن وثائق قليلة جدا ويمكن أيضا أن يسبب مشاكل للصيانة والاتصالات والتعلم وتبادل المعرفة. كتب اليستير كوكبرن من طريقة اضحة وضوح الشمس

اساليب رشيقه

أساليب تطوير البرمجيات رشيقة المعروفة تطوير البرمجيات التكيفية (ASD) النمذجة رشيقة العملية الموحدة رشيقة (AUP) الكريستال طرق واضحة الأنظمة الديناميكية طريقة وضع (DSDM) البرمجة المتطرفة (XP) التنمية المدفوعة باعتبارات ميزة (FDD) تطوير البرمجيات دعم دورة الحياة [29

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

التطبيق خارج تطوير البرمجيات

وقد أساليب رشيقة تستخدم على نطاق واسع لتطوير منتجات البرمجيات ومنهم من استخدام خصائص معينة من البرامج، مثل تقنيات الكائن. [76] ومع ذلك، هذه التقنيات يمكن تطبيقها لتطوير المنتجات غير البرمجيات، مثل أجهزة الكمبيوتر، والسيارات السيارات، والأجهزة الطبية والمواد الغذائية والملابس، والموسيقى، [77] انظر: تطوير المنتج المرن.

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

النقد

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

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

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

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

تطوير الهندسه الرشيقه

النهج السريع لتطوير البرمجيات تعتبر تصميم وتنفيذ لتكون الأنشطة المركزية في عملية البرمجيات. أنها تتضمن أنشطة أخرى، مثل متطلبات الاستنباط والاختبار، في التصميم والتنفيذ.

المواصفات والتصميم والتنفيذ والاختبار وبين الأوراق وقرر المخرجات من عملية التنمية من خلال عملية التفاوض خلال عملية تطوير البرمجيات

وعادة ما تستخدم الهندسه رشيقة في مجال تطوير البرمجيات لمساعدة الشركات على الاستجابة لعدم القدرة على التنبؤ.

في حين أن كل الطرق الرشيقة هي فريدة من نوعها في نهجها محددة، وأنهم جميعا تشترك في الرؤية المشتركة والقيم الأساسية

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

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

مشاكل اساليب الهندسه الرشيقه

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

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

تغييرات إعطاء الأولوية يمكن أن يكون صعبا حيث توجد العديد من أصحاب المصلحة. عادة، ويعطي كل صاحب مصلحة فقا لأولويات مختلفة للتغيرات مختلفة.

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