تطوير البرمجيات الرشيقة
تطوير البرمجيات الرشيقة هو مصطلح شامل لأساليب تطوير البرمجيات التي تعكس القيم والمبادئ التي اتفق عليها تحالف الرشاقة، وهو مجموعة من 17 ممارسًا للبرمجيات، في عام 2001. [ 1 ] وكما هو موثق في بيانهم لتطوير البرمجيات الرشيقة ، فإن الممارسين يقدرون ما يلي: [ 2 ]
- الأفراد والتفاعلات أهم من العمليات والأدوات
- برنامج تشغيل مدعوم بوثائق شاملة
- التعاون مع العملاء في مفاوضات العقود
- الاستجابة للتغيير وفقًا لخطة
يستشهد الممارسون بالإلهام من الممارسات الجديدة في ذلك الوقت، بما في ذلك البرمجة المتطرفة ، وسكروم ، ومنهجية تطوير الأنظمة الديناميكية ، وتطوير البرمجيات التكيفي ، والتعاطف مع الحاجة إلى بديل لعمليات تطوير البرمجيات الثقيلة والقائمة على التوثيق. [ 3 ]
انبثقت العديد من ممارسات تطوير البرمجيات من منهجية أجايل. وتشمل هذه الممارسات القائمة على أجايل، والتي تُسمى أحيانًا أجايل (بحرف أ كبير)، [ 4 ] تحديد المتطلبات، واكتشافها، وتحسين الحلول من خلال الجهد التعاوني لفرق العمل ذاتية التنظيم ومتعددة التخصصات مع عملائها / مستخدميها النهائيين . [ 5 ] [ 6 ]
على الرغم من وجود العديد من الأدلة القصصية التي تشير إلى أن عقلية أجايل والممارسات القائمة على أجايل تُحسّن عملية تطوير البرمجيات، إلا أن الأدلة التجريبية محدودة وغير قاطعة. [ 7 ] [ 8 ] [ 9 ]
تاريخ
يمكن تتبع أساليب تطوير البرمجيات التكرارية والتزايدية إلى عام 1957، [ 10 ] مع ظهور إدارة المشاريع التطورية [ 11 ] [ 12 ] وتطوير البرمجيات التكيفي [ 13 ] في أوائل السبعينيات. [ 14 ]
خلال تسعينيات القرن الماضي، ظهرت عدة أساليب لتطوير البرمجيات الخفيفة كرد فعل على الأساليب الثقيلة السائدة آنذاك (والتي يُشار إليها مجتمعةً باسم " النموذج التتابعي ")، والتي وصفها النقاد بأنها مفرطة التنظيم والتخطيط والإدارة التفصيلية . [ 15 ] شملت هذه الأساليب الخفيفة التطوير السريع للتطبيقات (RAD) منذ عام 1991؛ [ 16 ] [ 17 ] والعملية الموحدة (UP) ومنهجية تطوير الأنظمة الديناميكية (DSDM)، وكلاهما منذ عام 1994؛ وسكروم منذ عام 1995؛ وكريستال كلير والبرمجة المتطرفة (XP)، وكلاهما منذ عام 1996؛ والتطوير الموجه بالميزات (FDD) منذ عام 1997. على الرغم من أن جميع هذه الأساليب نشأت قبل نشر بيان أجايل ، إلا أنها تُعرف الآن مجتمعةً باسم أساليب تطوير البرمجيات الرشيقة. [ 3 ]
كانت تغييرات مماثلة جارية بالفعل منذ عام 1991 في التصنيع [ 18 ] [ 19 ] والتفكير الإداري [ 20 ] المستمد من الإدارة الرشيقة .
في عام ٢٠٠١، اجتمع سبعة عشر مطور برمجيات في منتجع بمدينة سنوبيرد بولاية يوتا لمناقشة أساليب التطوير الرشيقة. وكان من بينهم: كينت بيك (البرمجة المتطرفة)، وورد كانينغهام (البرمجة المتطرفة)، وديف توماس ( البرمجة البراغماتية ، روبي)، وجيف ساذرلاند (سكروم)، وكين شوابر (سكروم)، وجيم هايسميث (التطوير البرمجي التكيفي)، وأليستر كوكبيرن (كريستال)، وروبرت سي. مارتن ( مبادئ SOLID )، ومايك بيدل (سكروم)، وآري فان بينيكوم، ومارتن فاولر ( التحليل والتحليل الموجه للكائنات ولغة النمذجة الموحدة )، وجيمس غرينينغ، وأندرو هانت (البرمجة البراغماتية، روبي)، ورون جيفريز (البرمجة المتطرفة)، وجون كيرن ، وبرايان ماريك (روبي، التطوير الموجه بالاختبار )، وستيف ميلور ( التحليل والتحليل الموجه للكائنات ). وقد نشرت المجموعة، المعروفة باسم "تحالف أجايل"، بيانًا لتطوير البرمجيات الرشيقة . [ ٢ ]
في عام 2005، كتبت مجموعة برئاسة كوكبيرن وهايسميث ملحقًا لمبادئ إدارة المشاريع ، وهو إعلان إدارة المشاريع عن الترابط، [ 21 ] لتوجيه إدارة مشاريع البرمجيات وفقًا لأساليب تطوير البرمجيات الرشيقة.
في عام 2009، قامت مجموعة تعمل مع مارتن بكتابة امتداد لمبادئ تطوير البرمجيات ، وهو بيان براعة البرمجيات ، لتوجيه تطوير البرمجيات الرشيقة وفقًا للسلوك المهني والإتقان.
في عام 2011، أنشأ التحالف الرشيق دليل الممارسات الرشيقة (أعيد تسميته إلى قاموس المصطلحات الرشيقة في عام 2016)، [ 22 ] وهو عبارة عن مجموعة مفتوحة المصدر متطورة من التعريفات العملية للممارسات الرشيقة والمصطلحات والعناصر، إلى جانب التفسيرات والمبادئ التوجيهية للتجربة من المجتمع العالمي لممارسي الرشاقة.
القيم والمبادئ
قيم
ينص بيان تطوير البرمجيات الرشيقة على ما يلي: [ 2 ]
نحن نكتشف طرقًا أفضل لتطوير البرمجيات من خلال ممارستها ومساعدة الآخرين على ممارستها. ومن خلال هذا العمل، توصلنا إلى تقدير ما يلي:
- الأفراد والتفاعلات أهم من العمليات والأدوات
- برنامج تشغيل مدعوم بوثائق شاملة
- التعاون مع العملاء في مفاوضات العقود
- الاستجابة للتغيير وفقًا لخطة
أي أنه على الرغم من وجود قيمة في العناصر الموجودة على اليمين، إلا أننا نقدر العناصر الموجودة على اليسار أكثر.
أوضح سكوت أمبلر : [ 23 ]
- تُعد الأدوات والعمليات مهمة، ولكن الأهم هو وجود أشخاص أكفاء يعملون معًا بفعالية.
- إن التوثيق الجيد مفيد في مساعدة الناس على فهم كيفية بناء البرنامج وكيفية استخدامه، ولكن الهدف الرئيسي من التطوير هو إنشاء البرامج وليس التوثيق.
- يُعدّ العقد مهماً، لكنه ليس بديلاً عن العمل عن كثب مع العملاء لاكتشاف ما يحتاجون إليه.
- تُعد خطة المشروع مهمة، ولكن يجب ألا تكون جامدة للغاية بحيث لا تستوعب التغييرات في التكنولوجيا أو البيئة، وأولويات أصحاب المصلحة، وفهم الناس للمشكلة وحلها.
قال جيم هايسميث ، مقدماً البيان نيابة عن تحالف أجايل:
لا تُعارض حركة أجايل المنهجيات، بل إن الكثيرين منا يسعون إلى إعادة المصداقية لكلمة "منهجية". نريد استعادة التوازن. نُؤيد النمذجة، ولكن ليس لمجرد حفظ مخطط في مستودع مؤسسي مُغبر. نُؤيد التوثيق، ولكن ليس لمئات الصفحات من المجلدات المهملة ونادراً ما تُستخدم. نُخطط، ولكن نُدرك حدود التخطيط في بيئة مُتقلبة. أولئك الذين يُصنفون مُؤيدي XP أو SCRUM أو أي من منهجيات أجايل الأخرى على أنهم "مُخترقون" يجهلون المنهجيات والتعريف الأصلي لمصطلح "مُخترق".
— جيم هايسميث، التاريخ: بيان أجايل [ 24 ]
مبادئ
تستند القيم إلى هذه المبادئ: [ 25 ]
- تحقيق رضا العملاء من خلال التسليم المبكر والمستمر للبرامج القيّمة.
- نرحب بالمتطلبات المتغيرة، حتى في المراحل المتأخرة من التطوير.
- قم بتسليم برامج عاملة بشكل متكرر (خلال أسابيع بدلاً من أشهر).
- تعاون وثيق ويومي بين رجال الأعمال والمطورين.
- تُبنى المشاريع حول أفراد متحمسين، يجب أن يكونوا جديرين بالثقة.
- المحادثة وجهاً لوجه هي أفضل أشكال التواصل (التواجد في نفس المكان).
- يُعدّ البرنامج العامل المقياس الأساسي للتقدم.
- التنمية المستدامة، القادرة على الحفاظ على وتيرة ثابتة.
- الاهتمام المستمر بالتميز التقني والتصميم الجيد.
- البساطة - فن تقليل كمية العمل غير المنجز إلى الحد الأدنى - أمر ضروري.
- أفضل البنى والمتطلبات والتصاميم تنبثق من فرق ذاتية التنظيم.
- يقوم الفريق بانتظام بالتفكير في كيفية أن يصبح أكثر فعالية، ويجري التعديلات اللازمة وفقًا لذلك.
ملخص
تكراري، وتزايدي، وتطوري
تُقسّم معظم منهجيات التطوير الرشيقة عملية تطوير المنتج إلى مراحل صغيرة ، مما يُقلل من التخطيط والتصميم المُسبقين. تُعرف هذه المراحل بالتكرارات، أو دورات التطوير السريعة، وهي عبارة عن فترات زمنية قصيرة [ 26 ] تتراوح عادةً بين أسبوع وأربعة أسابيع. [ 27 ] : 20 تتضمن كل دورة فريقًا متعدد التخصصات يعمل في جميع الوظائف: التخطيط ، والتحليل ، والتصميم ، والبرمجة ، واختبار الوحدات ، واختبار القبول . في نهاية كل دورة، يتم عرض منتج جاهز للاستخدام على أصحاب المصلحة. يُقلل هذا من المخاطر الإجمالية ويُمكّن المنتج من التكيف مع التغييرات بسرعة. [ 28 ] [ 29 ] قد لا تُضيف الدورة وظائف كافية لتبرير طرح المنتج في السوق، ولكن الهدف هو توفير إصدار مُتاح (بأقل قدر من الأخطاء ) في نهاية كل دورة. [ 30 ] من خلال التطوير التدريجي، تُتاح للمنتجات فرصة " الفشل المُتكرر والمبكر " خلال كل مرحلة تكرارية، بدلاً من الفشل بشكل جذري في تاريخ الإصدار النهائي. [ 31 ] قد يتطلب إطلاق منتج أو ميزات جديدة عدة دورات تطوير. ويُعدّ البرنامج العامل المقياس الأساسي للتقدم. [ 25 ]
التواصل الفعال والمباشر
ينص المبدأ السادس من بيان أجايل لتطوير البرمجيات على أن "الطريقة الأكثر كفاءة وفعالية لنقل المعلومات داخل فريق التطوير هي المحادثة وجهاً لوجه". وقد ورد هذا المبدأ في البيان، الذي كُتب عام ٢٠٠١ عندما لم تكن تقنية مؤتمرات الفيديو شائعة الاستخدام، فيما يتعلق بنقل المعلومات، وليس بالضرورة أن يكون الفريق متواجداً في مكان واحد.
يقوم مبدأ التواجد المشترك على وجود أعضاء الفريق الواحد في مكان واحد لتعزيز هوية الفريق وتحسين التواصل. [ 32 ] يتيح ذلك التفاعل المباشر ، ويفضل أن يكون ذلك أمام لوحة بيضاء، مما يقلل من الوقت اللازم عادةً لتبادل الأسئلة والأجوبة عبر الهاتف أو الدردشة المستمرة أو مواقع الويكي أو البريد الإلكتروني. [ 33 ] مع الانتشار الواسع للعمل عن بُعد خلال جائحة كوفيد-19 والتغيرات التي طرأت على الأدوات، أُجريت المزيد من الدراسات [ 34 ] حول التواجد المشترك والعمل الموزع، والتي تُظهر أن أهمية التواجد المشترك تتضاءل تدريجيًا.
بغض النظر عن منهجية التطوير المُتبعة، يجب أن يضم كل فريق ممثلاً للعميل (يُعرف بمالك المنتج في منهجية سكروم ). يُختار هذا الممثل من قِبل أصحاب المصلحة ليمثلهم، ويلتزم شخصيًا بتوفير الدعم للمطورين والإجابة على استفساراتهم طوال دورة التطوير. في نهاية كل دورة، يُراجع أصحاب المصلحة في المشروع ، بالتعاون مع ممثل العميل، التقدم المُحرز ويُعيدون تقييم الأولويات بهدف تحسين عائد الاستثمار وضمان التوافق مع احتياجات العميل وأهداف الشركة. إن أهمية رضا أصحاب المصلحة، والتي تتجلى من خلال التفاعل والمراجعة المُستمرة في نهاية كل مرحلة، هي السبب في أن هذا النهج يُوصف غالبًا بأنه منهجية تتمحور حول العميل . [ 35 ]
مشعاع المعلومات
في تطوير البرمجيات الرشيقة، تُعدّ لوحة المعلومات شاشة عرض مادية (كبيرة عادةً) أو لوحة عليها ملاحظات لاصقة أو ما شابه، توضع في مكان بارز بالقرب من فريق التطوير، بحيث يراها المارة. [ 36 ] وهي تعرض ملخصًا محدّثًا لحالة تطوير المنتج. [ 37 ] كما يمكن استخدام مؤشر ضوئي لإعلام الفريق بالحالة الراهنة لتطوير منتجهم.
حلقة تغذية راجعة قصيرة جدًا ودورة تكيف قصيرة جدًا
من السمات الشائعة في تطوير البرمجيات الرشيقة الاجتماع اليومي السريع (المعروف باسم "اجتماع سكروم اليومي " في إطار عمل سكروم). في جلسة قصيرة (مثلاً، 15 دقيقة)، يستعرض أعضاء الفريق بشكل جماعي مدى تقدمهم نحو هدفهم ويتفقون على ما إذا كانوا بحاجة إلى تعديل أسلوبهم. وللالتزام بالوقت المتفق عليه، غالبًا ما تستخدم الفرق أسئلة بسيطة مُرمّزة (مثل ما أنجزوه في اليوم السابق، وما يهدفون إلى إنجازه في ذلك اليوم، وما إذا كانت هناك أي عوائق أو مخاطر تعترض التقدم)، وتؤجل المناقشات التفصيلية وحل المشكلات إلى ما بعد الاجتماع السريع. [ 38 ]
التركيز على الجودة
تُستخدم أدوات وتقنيات محددة، مثل التكامل المستمر ، واختبار الوحدات الآلي ، والبرمجة الثنائية ، والتطوير القائم على الاختبار ، وأنماط التصميم ، والتطوير القائم على السلوك ، والتصميم القائم على المجال، وإعادة هيكلة الكود ، وغيرها من التقنيات، لتحسين الجودة وتعزيز مرونة تطوير المنتج. [ 39 ] ويعتمد ذلك على تصميم وبناء الجودة منذ البداية، والقدرة على عرض البرمجيات للعملاء في أي مرحلة، أو على الأقل في نهاية كل دورة تطوير. [ 40 ]
فلسفة
بالمقارنة مع هندسة البرمجيات التقليدية، يستهدف تطوير البرمجيات الرشيقة بشكل أساسي الأنظمة المعقدة وتطوير المنتجات ذات الخصائص الديناميكية وغير الحتمية وغير الخطية . غالبًا ما يصعب الحصول على تقديرات دقيقة وخطط مستقرة وتنبؤات في المراحل المبكرة، ومن المرجح أن تكون الثقة بها منخفضة. يستخدم ممارسو منهجية أجايل إرادتهم الحرة لتقليل " القفزة الإيمانية " اللازمة قبل الحصول على أي دليل على القيمة . [ 41 ] يُنظر إلى المتطلبات والتصميم على أنهما ناشئان . من المحتمل أن تتسبب المواصفات الكبيرة المسبقة في الكثير من الهدر في مثل هذه الحالات، أي أنها غير مجدية اقتصاديًا. ساعدت هذه الحجج الأساسية وخبرات الصناعة السابقة ، المستقاة من سنوات من النجاحات والإخفاقات، في تشكيل ميل تطوير البرمجيات الرشيقة نحو التطوير التكيفي والتكراري والتطوري. [ 42 ]
التكيفي مقابل التنبؤي
تتنوع أساليب التطوير بين التكيفية والتنبؤية . [ 43 ] تقع أساليب تطوير البرمجيات الرشيقة على الجانب التكيفي من هذا الطيف. ومن أهم سمات أساليب التطوير التكيفية اتباع نهج الموجة المتغيرة في تخطيط الجدول الزمني، والذي يحدد المعالم الرئيسية مع إتاحة المرونة في مسار الوصول إليها، كما يسمح بتغيير هذه المعالم نفسها. [ 44 ]
تركز الأساليب التكيفية على التكيف السريع مع المتغيرات. فعندما تتغير احتياجات المشروع، يتغير الفريق التكيفي تبعًا لذلك. ويواجه هذا الفريق صعوبة في وصف ما سيحدث في المستقبل بدقة. فكلما ابتعد التاريخ، كلما ازداد غموض الأسلوب التكيفي فيما يتعلق بما سيحدث في ذلك التاريخ. لا يستطيع الفريق التكيفي تحديد المهام التي سينجزها الأسبوع المقبل بدقة، بل يكتفي بالإبلاغ عن الميزات التي يخطط لها الشهر المقبل. وعند سؤاله عن إصدار بعد ستة أشهر، قد يكتفي الفريق التكيفي بذكر بيان مهمة الإصدار، أو بيان القيمة المتوقعة مقابل التكلفة.
على النقيض من ذلك، تركز الأساليب التنبؤية على تحليل وتخطيط المستقبل بتفصيل دقيق، مع مراعاة المخاطر المعروفة. وفي الحالات القصوى، يستطيع فريق التنبؤ تحديد الميزات والمهام المخطط لها بدقة طوال عملية التطوير. تعتمد هذه الأساليب على تحليل فعال في المراحل المبكرة، وإذا لم ينجح هذا التحليل، فقد يواجه المشروع صعوبة في تغيير مساره. ولذلك، غالبًا ما تُنشئ فرق التنبؤ مجلسًا لمراقبة التغييرات لضمان النظر فقط في التغييرات الأكثر أهمية.
يمكن استخدام تحليل المخاطر للاختيار بين الأساليب التكيفية ( المرنة أو القائمة على القيمة ) والأساليب التنبؤية ( القائمة على التخطيط ). [ 45 ] ويشير باري بوهم وريتشارد تيرنر إلى أن لكل جانب من جوانب هذا الطيف مجاله الخاص ، كما يلي: [ 46 ]
| الأساليب القائمة على القيمة (الرشاقة) | الأساليب القائمة على التخطيط (الأسلوب التتابعي) | الأساليب الرسمية |
|---|---|---|
| حرج منخفض | أهمية بالغة | حرج للغاية |
| مطورون كبار | مطورون مبتدئون (؟) | مطورون كبار |
| تتغير المتطلبات بشكل متكرر | لا تتغير المتطلبات كثيراً | متطلبات محدودة، ميزات محدودة، انظر قانون ويرث |
| عدد قليل من المطورين | عدد كبير من المطورين | المتطلبات التي يمكن نمذجتها |
| ثقافة تستجيب للتغيير | ثقافة تتطلب النظام | جودة فائقة |
أجايل مقابل ووترفول
يُعدّ أسلوب التعامل مع الجودة والاختبار أحد الفروقات بين منهجيات تطوير البرمجيات الرشيقة ومنهجية الشلال. ففي نموذج الشلال ، ينتقل العمل عبر مراحل دورة حياة تطوير البرمجيات (SDLC)، حيث تُستكمل كل مرحلة قبل البدء بالمرحلة التالية، ولذلك تكون مرحلة الاختبار منفصلة وتلي مرحلة البناء . أما في تطوير البرمجيات الرشيقة، فيُستكمل الاختبار في نفس دورة البرمجة.
بما أن الاختبار يُجرى في كل دورة تطوير - والتي تُطوّر جزءًا صغيرًا من البرنامج - يُمكن للمستخدمين استخدام هذه الأجزاء الجديدة من البرنامج بشكل متكرر والتحقق من قيمتها. بعد أن يُدرك المستخدمون القيمة الحقيقية للبرنامج المُحدّث، يُمكنهم اتخاذ قرارات أفضل بشأن مستقبل البرنامج. إنّ عقد جلسة استعراض القيمة وإعادة تخطيط البرنامج في كل دورة تطوير - والتي تستغرق عادةً أسبوعين فقط في منهجية سكروم - يُساعد الفريق على تعديل خططه باستمرار لتعظيم القيمة التي يُقدّمها. ويتبع هذا نمطًا مشابهًا لدورة التخطيط والتنفيذ والتحقق والتحسين (PDCA)، حيث يتم تخطيط العمل ، وإنجازه ، والتحقق منه (في جلسة المراجعة وجلسة استعراض القيمة)، ويتم العمل على أي تغييرات مُتفق عليها.
يدعم هذا النهج التكراري عقلية المنتج بدلاً من عقلية المشروع . وهذا يوفر مرونة أكبر طوال عملية التطوير؛ بينما في المشاريع، تُحدد المتطلبات وتُثبت منذ البداية، مما يجعل تغييرها لاحقاً أمراً صعباً. يسمح تطوير المنتج التكراري للبرنامج بالتطور استجابةً للتغيرات في بيئة الأعمال أو متطلبات السوق.
الكود مقابل التوثيق
في رسالة إلى مجلة IEEE Computer ، أعرب ستيفن راكيتين عن تشككه بشأن تطوير البرمجيات الرشيقة، واصفاً إياه بأنه "محاولة أخرى لتقويض تخصص هندسة البرمجيات"، وترجم عبارة "برمجيات عاملة بدلاً من توثيق شامل" إلى "نريد أن نقضي كل وقتنا في كتابة الأكواد. تذكروا، المبرمجون الحقيقيون لا يكتبون التوثيق". [ 47 ]
يُعارض هذا الرأي مؤيدو تطوير البرمجيات الرشيقة، الذين يرون أنه ينبغي على المطورين كتابة التوثيق إذا كانت هذه هي أفضل طريقة لتحقيق الأهداف المرجوة، ولكن غالبًا ما توجد طرق أفضل لتحقيق تلك الأهداف من كتابة توثيق ثابت. [ 48 ] ويذكر سكوت أمبلر أن التوثيق يجب أن يكون "جيدًا بما يكفي" (JBGE)، [ 49 ] وأن الإفراط في التوثيق أو شموله يُؤدي عادةً إلى الهدر، ونادرًا ما يثق المطورون في التوثيق المُفصّل لأنه عادةً ما يكون غير متوافق مع الكود، [ 48 ] في حين أن قلة التوثيق قد تُسبب أيضًا مشاكل في الصيانة والتواصل والتعلم وتبادل المعرفة. وقد كتب أليستير كوكبيرن عن منهجية كريستال كلير :
تعتبر كريستال عملية التطوير سلسلة من الألعاب التعاونية، وتعتزم أن تكون الوثائق كافية لمساعدة الفريق التالي على تحقيق النجاح في اللعبة التالية. تشمل مخرجات عمل كريستال حالات الاستخدام، وقائمة المخاطر، وخطة التكرار، ونماذج المجال الأساسية، وملاحظات التصميم لإرشاد الفريق في اتخاذ القرارات... ومع ذلك، لا توجد قوالب جاهزة لهذه الوثائق، وتكون الأوصاف غامضة بالضرورة، لكن الهدف واضح: توفير قدر كافٍ من الوثائق للعبة التالية. أميل دائمًا إلى توضيح هذا الأمر لفريقي على النحو التالي: ما الذي ترغبون بمعرفته لو انضممتم إلى الفريق غدًا؟
— أليستير كوكبيرن [ 50 ]
طُرق
تدعم أساليب تطوير البرمجيات الرشيقة نطاقًا واسعًا من دورة حياة تطوير البرمجيات . [ 51 ] تركز بعض الأساليب على الممارسات (مثل البرمجة القصوى ، والبرمجة العملية ، والنمذجة الرشيقة)، بينما يركز بعضها الآخر على إدارة سير العمل (مثل سكروم، وكانبان). يدعم بعضها أنشطة تحديد المتطلبات والتطوير (مثل FDD )، بينما يسعى بعضها الآخر إلى تغطية دورة حياة التطوير بالكامل (مثل DSDM ، و RUP ).
تشمل أطر تطوير البرمجيات الرشيقة البارزة ما يلي:
| نطاق | المساهم الرئيسي (المساهمون الرئيسيون) |
|---|---|
| تطوير البرمجيات التكيفي (ASD) | جيم هايسميث ، سام باير |
| النمذجة الرشيقة | سكوت أمبلر ، روبرت سيسيل مارتن |
| عملية موحدة مرنة (AUP) | سكوت أمبلر |
| التسليم الرشيق المنضبط | سكوت أمبلر |
| أسلوب تطوير الأنظمة الديناميكية (DSDM) | جينيفر ستابلتون |
| البرمجة المتطرفة (XP) | كينت بيك ، روبرت سيسيل مارتن |
| التطوير القائم على الميزات (FDD) | جيف دي لوكا |
| تطوير البرمجيات الرشيقة | ماري بوبنديك، توم بوبنديك |
| الشركات الناشئة المرنة | إريك ريس |
| كانبان | تايتشي أونو |
| تطوير التطبيقات السريع (RAD) | جيمس مارتن |
| سكروم | كين شوابر ، جيف ساذرلاند |
| سكرومبان |
ممارسات تطوير البرمجيات الرشيقة
يدعم تطوير البرمجيات الرشيقة عدد من الممارسات الملموسة، التي تغطي مجالات مثل المتطلبات والتصميم والنمذجة والبرمجة والاختبار والتخطيط وإدارة المخاطر والعمليات والجودة، وما إلى ذلك. تتضمن بعض ممارسات تطوير البرمجيات الرشيقة البارزة ما يلي: [ 52 ]
| يمارس | المساهم الرئيسي (المساهمون الرئيسيون) |
|---|---|
| تطوير البرمجيات الموجه باختبارات القبول (ATDD) | كين بو |
| النمذجة الرشيقة | سكوت أمبلر |
| اختبار أجايل | ليزا كريسبين، جانيت غريغوري |
| قوائم المهام المتراكمة (المنتج والسباق) | كين شوابر ، جيف ساذرلاند |
| التطوير القائم على السلوك (BDD) | دان نورث، ليز كيو |
| التكامل المستمر (CI) | جرادي بوتش |
| فريق متعدد الوظائف | |
| الاجتماع اليومي / اجتماع سكروم اليومي | جيمس أو كوبلين |
| التصميم الموجه بالمجال (DDD) | إريك إيفانز |
| التطوير التكراري والتراكمي (IID) | |
| البرمجة الثنائية | كينت بيك |
| تخطيط لعبة البوكر | جيمس غرينينغ، مايك كوهن |
| إعادة هيكلة | مارتن فاولر |
| دراسة استرجاعية | إستير ديربي، ديانا لارسن، بن ليندرز، لويس غونسالفيس |
| فعاليات سكروم (تخطيط دورة التطوير، مراجعة دورة التطوير، واستعراض الأداء) | كين شوابر ، جيف ساذرلاند |
| المواصفات من خلال المثال | |
| النمذجة القائمة على القصة | ألبرت زوندورف |
| تطوير البرمجيات الموجه بالاختبار (TDD) | كينت بيك |
| تحديد الوقت | |
| قصة المستخدم | أليستير كوكبيرن |
| تتبع السرعة |
تطوير قائم على اختبار القبول
تطوير البرمجيات الموجه باختبارات القبول (ATDD) هو منهجية تطوير تعتمد على التواصل بين عملاء الأعمال والمطورين والمختبرين. [ 53 ] يشمل ATDD العديد من الممارسات نفسها التي تشملها منهجية تحديد المواصفات بالأمثلة (SBE)، [ 54 ] [ 55 ] والتطوير الموجه بالسلوك (BDD)، [ 56 ] والتطوير الموجه بالأمثلة (EDD)، [ 57 ] والتطوير الموجه بالدعم، والذي يُسمى أيضًا التطوير الموجه باختبارات القصص (SDD). [ 58 ] تساعد جميع هذه العمليات المطورين والمختبرين على فهم احتياجات العميل قبل التنفيذ، وتتيح للعملاء التواصل بلغة مجالهم.
النمذجة الرشيقة
النمذجة الرشيقة (AM) هي منهجية لنمذجة وتوثيق أنظمة البرمجيات استنادًا إلى أفضل الممارسات. وهي عبارة عن مجموعة من القيم والمبادئ التي يمكن تطبيقها على مشروع تطوير برمجيات (رشيق). تتميز هذه المنهجية بمرونة أكبر من أساليب النمذجة التقليدية، مما يجعلها أكثر ملاءمةً لبيئة سريعة التغير. [ 59 ] وهي جزء من مجموعة أدوات تطوير البرمجيات الرشيقة.
اختبار أجايل
اختبار البرمجيات الرشيق هو ممارسة لاختبار البرمجيات تتبع مبادئ تطوير البرمجيات الرشيقة. يشمل هذا الاختبار جميع أعضاء فريق رشيق متعدد التخصصات، مع إسهامات متخصصة من المختبرين، لضمان تقديم القيمة المرجوة للعميل على فترات متقاربة، بوتيرة مستدامة. ويُستخدم التحديد بالأمثلة لتوثيق أمثلة السلوك المرغوب وغير المرغوب فيه، وتوجيه عملية البرمجة.
المتراكمات
في إدارة المشاريع الرشيقة ، تشير قائمة مهام المنتج إلى قائمة مُرتبة حسب الأولوية للوظائف التي يجب أن يتضمنها المنتج. ويُشار إليها أحيانًا بقائمة المهام ، [ 60 ] وتُعتبر "مُخرجًا" (شكلًا من أشكال التوثيق) ضمن إطار عمل تطوير البرمجيات سكروم . [ 61 ] وتُستخدم أسماء مختلفة لقائمة مهام المنتج في أطر إدارة المشاريع المختلفة، مثل قائمة مهام المنتج في سكروم، [ 61 ] [ 62 ] وقائمة عناصر العمل في منهجية أجايل المنضبطة ، [ 62 ] [ 63 ] ومجموعة الخيارات في منهجية لين . [ 62 ] في إطار عمل سكروم، يُعد إنشاء قائمة مهام المنتج وصيانتها المستمرة جزءًا من مسؤولية مالك المنتج . [ 64 ]
التنمية القائمة على السلوك
تطوير البرمجيات الموجه بالسلوك (BDD) هو منهجية تطوير برمجيات مرنة تتمحور حول التعاون بين متخصصي الأعمال وتكنولوجيا المعلومات الذين لديهم مصلحة في إيجاد حل لمشكلة معقدة. والهدف الأساسي هو تحقيق فهم مشترك للمشكلة. [ 65 ]
التكامل المستمر
التكامل المستمر (CI) هو ممارسة دمج تغييرات شفرة المصدر بشكل متكرر وضمان أن قاعدة الشفرة المدمجة في حالة قابلة للتشغيل. عادةً، يقوم المطورون بدمج التغييرات في فرع التكامل ، ثم يقوم نظام آلي ببناء واختبار نظام البرمجيات . [ 66 ] غالبًا ما تُنفَّذ العملية الآلية مع كل عملية إيداع أو وفقًا لجدول زمني، كأن تُنفَّذ مرة واحدة يوميًا. اقترح جرادي بوتش مصطلح التكامل المستمر لأول مرة عام 1991 ، [ 67 ] على الرغم من أنه لم يكن يدعو إلى التكامل عدة مرات في اليوم، ولكن لاحقًا، أصبح التكامل المستمر يشمل هذا الجانب. [ 68 ]
فريق متعدد الوظائف
الفريق متعدد الوظائف (XFN)، المعروف أيضًا بالفريق متعدد التخصصات أو الفريق المتداخل التخصصات، هو مجموعة من الأفراد ذوي الخبرات الوظيفية المختلفة الذين يعملون لتحقيق هدف مشترك. [ 69 ] قد يضم هذا الفريق أفرادًا من أقسام المالية والتسويق والعمليات والموارد البشرية . وعادةً ما يضم موظفين من جميع مستويات المؤسسة. كما قد يأتي أعضاؤه من خارج المؤسسة (وخاصةً من الموردين أو العملاء الرئيسيين أو الاستشاريين).
ستاند أب كوميدي يومي
الاجتماع الذي يُعقد وقوفاً (STUM [ 70 ] ) هو اجتماع يشارك فيه الحضور عادةً وهم واقفون ، وعادةً ما يكون ذلك في حوالي الساعة العاشرة صباحاً. ويهدف عدم الراحة الناتج عن الوقوف لفترات طويلة إلى إبقاء الاجتماعات قصيرة.
تخصيص الأساليب
في الأدبيات، تُستخدم مصطلحات مختلفة للإشارة إلى مفهوم تكييف المنهج، بما في ذلك "تخصيص المنهج"، و"تكييف أجزاء المنهج"، و"هندسة المنهج الظرفية". ويُعرَّف تخصيص المنهج على النحو التالي:
عملية أو قدرة يقوم فيها الفاعلون البشريون بتحديد نهج تطوير النظام لحالة مشروع محددة من خلال التغييرات الاستجابية والتفاعلات الديناميكية بين السياقات والنوايا وأجزاء المنهجية.
— محمد نافيز أيدين وآخرون، طريقة تطوير نظم المعلومات الرشيقة قيد الاستخدام [ 71 ]
ينبغي اعتبار ملاءمة الموقف سمةً مميزةً بين منهجيات التطوير الرشيقة ومنهجيات تطوير البرمجيات القائمة على التخطيط، حيث تسمح المنهجيات الرشيقة لفرق تطوير المنتجات بتكييف ممارسات العمل وفقًا لاحتياجات كل منتج على حدة. [ 72 ] [ 71 ] ومن المحتمل أن تكون معظم المنهجيات الرشيقة قابلةً للتخصيص، [ 51 ] مثل منهجية DSDM المُخصصة في سياق نموذج نضج القدرات (CMM) . [ 73 ] ومنهجية XP المُخصصة بتقنية ممارسات وصف القواعد (RDP). [ 74 ] ومع ذلك، لا يتفق جميع مؤيدي المنهجيات الرشيقة، حيث أشار شوابر إلى أن "هذه هي الطريقة التي وقعنا بها في المشكلة في المقام الأول، إذ اعتقدنا أن المشكلة تكمن في عدم وجود منهجية مثالية. ينبغي أن تتركز الجهود على التغييرات المطلوبة في المؤسسة". [ 75 ] عزز باس فود هذا الرأي، مشيرًا إلى أنه على عكس المنهجيات التقليدية واسعة النطاق التي تتطلب انتقاء العناصر، يوفر سكروم الأساسيات التي تُضاف إليها عناصر إضافية لتخصيص استخدامها وتكييفه مع السياق المحلي. [ 76 ] نادرًا ما يستخدم الممارسون أساليب تطوير الأنظمة ، أو أساليب أجايل تحديدًا، بشكل حرفي، وغالبًا ما يختارون حذف بعض ممارسات المنهجية أو تعديلها لإنشاء منهجية داخلية. [ 77 ]
عمليًا، يمكن تخصيص الأساليب باستخدام أدوات متنوعة. يمكن استخدام لغات نمذجة العمليات العامة، مثل لغة النمذجة الموحدة (UML)، لتخصيص أساليب تطوير البرمجيات. ومع ذلك، توجد أيضًا أدوات متخصصة لهندسة الأساليب، مثل نظرية جوهر هندسة البرمجيات ( SEMAT) . [ 78 ]
واسعة النطاق، بحرية وموزعة
يُنظر إلى تطوير البرمجيات الرشيقة على نطاق واسع على أنه مناسب للغاية لأنواع معينة من البيئات، بما في ذلك فرق الخبراء الصغيرة التي تعمل على مشاريع جديدة تمامًا ، [ 46 ] [ 79 ] والتحديات والقيود التي تواجه تبني أساليب تطوير البرمجيات الرشيقة في مؤسسة كبيرة ذات بنية تحتية قديمة موثقة ومفهومة جيدًا. [ 80 ]
واستجابة لذلك، تطورت مجموعة من الاستراتيجيات والأنماط للتغلب على التحديات المتعلقة بجهود التطوير واسعة النطاق (>20 مطورًا) [ 81 ] [ 82 ] أو فرق التطوير الموزعة (غير المتواجدة في نفس الموقع) [ 83 ] [ 84 ] من بين تحديات أخرى؛ وهناك الآن العديد من الأطر المعترف بها التي تسعى إلى التخفيف من هذه التحديات أو تجنبها.
توجد العديد من وجهات النظر المتضاربة حول ما إذا كانت جميع هذه الأساليب فعالة أم أنها تتناسب فعلاً مع تعريف التطوير الرشيق، ولا يزال هذا مجالاً نشطاً ومستمراً للبحث. [ 81 ] [ 85 ]
عند تطبيق منهجية تطوير البرمجيات الرشيقة في بيئة موزعة (مع فرق عمل موزعة على مواقع أعمال متعددة)، يُشار إليها عادةً باسم تطوير البرمجيات الرشيقة الموزعة . والهدف هو الاستفادة من المزايا الفريدة التي توفرها كل منهجية. يسمح التطوير الموزع للمؤسسات ببناء البرمجيات من خلال إنشاء فرق عمل استراتيجية في مناطق مختلفة من العالم، مما يتيح بناء البرمجيات على مدار الساعة تقريبًا (وهو ما يُعرف بنموذج العمل المتواصل). من ناحية أخرى، يوفر التطوير الرشيق مزيدًا من الشفافية، والتغذية الراجعة المستمرة، ومرونة أكبر في الاستجابة للتغييرات.
المجالات الخاضعة للتنظيم
كان يُنظر إلى أساليب تطوير البرمجيات الرشيقة في البداية على أنها الأنسب لتطوير المنتجات غير الحرجة، وبالتالي استُبعدت من الاستخدام في المجالات الخاضعة للتنظيم مثل الأجهزة الطبية ، والصناعات الدوائية، والمالية، والأنظمة النووية، والسيارات، والإلكترونيات الطيران، وغيرها. ومع ذلك، شهدت السنوات القليلة الماضية العديد من المبادرات لتكييف أساليب التطوير الرشيقة مع هذه المجالات. [ 86 ] [ 87 ] [ 88 ] [ 89 ] [ 90 ]
توجد معايير عديدة قد تنطبق في المجالات الخاضعة للتنظيم، بما في ذلك ISO 26262 و ISO 9000 و ISO 9001 و ISO/IEC 15504. وهناك عدد من الاعتبارات الرئيسية ذات أهمية خاصة في المجالات الخاضعة للتنظيم: [ 91 ]
- ضمان الجودة (QA): إدارة الجودة المنهجية والمتأصلة التي تدعم عملية مهنية خاضعة للرقابة وموثوقية المنتج وصحته.
- السلامة والأمن: التخطيط الرسمي وإدارة المخاطر للتخفيف من مخاطر السلامة للمستخدمين وحماية المستخدمين بشكل آمن من سوء الاستخدام غير المقصود والخبيث.
- إمكانية التتبع : توفير وثائق تقدم أدلة قابلة للتدقيق على الامتثال التنظيمي وتسهل إمكانية التتبع والتحقيق في المشاكل.
- التحقق والتحقق من الصحة (V&V): مضمنة في جميع مراحل عملية تطوير البرمجيات (على سبيل المثال، مواصفات متطلبات المستخدم، والمواصفات الوظيفية، ومواصفات التصميم، ومراجعة التعليمات البرمجية، واختبارات الوحدة، واختبارات التكامل، واختبارات النظام).
الخبرة والتبني
على الرغم من إمكانية استخدام أساليب تطوير البرمجيات الرشيقة مع أي نموذج أو لغة برمجة عمليًا، إلا أنها كانت في الأصل مرتبطة ارتباطًا وثيقًا ببيئات البرمجة الكائنية مثل Smalltalk وLisp، ولاحقًا Java وC#. وكانت الفرق الصغيرة والمتوسطة الحجم هي أول من تبنى هذه الأساليب، حيث كانت تعمل على أنظمة غير مسبوقة ذات متطلبات يصعب تحديدها بدقة، ومن المرجح أن تتغير أثناء تطوير النظام. يصف هذا القسم المشكلات الشائعة التي تواجهها المؤسسات عند محاولتها تبني أساليب تطوير البرمجيات الرشيقة، بالإضافة إلى تقنيات متنوعة لقياس جودة وأداء فرق التطوير الرشيقة. [ 92 ]
قياس المرونة
التقييمات الداخلية
يُقيّم مؤشر قياس المرونة ، من بين مؤشرات أخرى، التطورات وفقًا لخمسة أبعاد لتطوير المنتج (المدة، والمخاطر، والابتكار، والجهد، والتفاعل). [ 93 ] وتعتمد تقنيات أخرى على أهداف قابلة للقياس [ 94 ] ، وتشير إحدى الدراسات إلى إمكانية استخدام السرعة كمقياس للمرونة. كما توجد تقييمات ذاتية للمرونة لتحديد ما إذا كان الفريق يستخدم ممارسات تطوير البرمجيات الرشيقة (اختبار نوكيا، [ 95 ] اختبار كارلسكرونا، [ 96 ] اختبار 42 نقطة). [ 97 ]
استطلاعات الرأي العام
إحدى الدراسات المبكرة التي أبلغت عن مكاسب في الجودة والإنتاجية ورضا الأعمال من خلال استخدام أساليب تطوير البرمجيات الرشيقة كانت دراسة استقصائية أجرتها شركة Shine Technologies في الفترة من نوفمبر 2002 إلى يناير 2003. [ 98 ]
يُجرى استطلاع مماثل، بعنوان " حالة منهجية أجايل "، سنويًا منذ عام 2006 بمشاركة آلاف الأشخاص من مختلف أنحاء مجتمع تطوير البرمجيات. ويتتبع هذا الاستطلاع الاتجاهات المتعلقة بالفوائد المتوقعة من منهجية أجايل، والدروس المستفادة، وأفضل الممارسات. وقد أشار كل استطلاع إلى تزايد أعداد من يؤكدون أن تطوير البرمجيات باستخدام منهجية أجايل يساعدهم على تسليم البرمجيات بشكل أسرع، ويُحسّن قدرتهم على إدارة أولويات العملاء المتغيرة، ويزيد من إنتاجيتهم. [ 99 ] كما أظهرت الاستطلاعات باستمرار نتائج أفضل مع أساليب تطوير المنتجات باستخدام منهجية أجايل مقارنةً بإدارة المشاريع التقليدية. [ 100 ] [ 101 ] في المقابل، تشير بعض التقارير إلى أن البعض يرى أن أساليب التطوير باستخدام منهجية أجايل لا تزال حديثة العهد بحيث لا تسمح بإجراء بحوث أكاديمية معمقة حول نجاحها. [ 102 ]
مآزق شائعة في تطوير البرمجيات الرشيقة
غالباً ما تواجه المؤسسات والفرق التي تطبق منهجية تطوير البرمجيات الرشيقة صعوبات في الانتقال من الأساليب التقليدية، مثل منهجية الشلال ، حيث تُفرض على بعض الفرق عملية رشيقة. [ 103 ] تُعرف هذه الصعوبات عادةً باسم " أنماط التطوير الرشيقة السلبية" أو " مؤشرات ضعف منهجية التطوير الرشيقة" . فيما يلي بعض الأمثلة الشائعة:
افتقار المنتج إلى تصميم شامل
يهدف تطوير البرمجيات الرشيقة إلى التركيز بشكل أكبر على إنتاج برمجيات عاملة وأقل على التوثيق. وهذا يختلف عن نماذج الشلال، حيث تكون العملية غالبًا شديدة التحكم، وتتطلب التغييرات الطفيفة في النظام مراجعة شاملة للوثائق الداعمة. مع ذلك، لا يُبرر هذا الاستغناء التام عن التحليل والتصميم. فإهمال التصميم قد يدفع الفريق إلى التقدم بسرعة في البداية، ثم إلى إعادة العمل بشكل كبير عند محاولة توسيع نطاق النظام. من أبرز سمات تطوير البرمجيات الرشيقة أنها عملية تكرارية. فعند تطبيقها بشكل صحيح، تسمح هذه المنهجية للتصميم بالظهور تدريجيًا مع تطور النظام، وتساعد الفريق على اكتشاف أوجه التشابه وفرص إعادة الاستخدام. [ 104 ]
إضافة قصص إلى نسخة قيد التطوير
في تطوير البرمجيات الرشيقة، تُستخدم القصص (المشابهة لوصف حالات الاستخدام ) عادةً لتحديد المتطلبات، وتُمثل الدورة فترة زمنية قصيرة يلتزم خلالها الفريق بأهداف محددة. [ 105 ] إن إضافة قصص إلى دورة جارية يُعيق سير العمل بسلاسة. لذا، ينبغي إضافتها إلى قائمة مهام المنتج وتحديد أولوياتها لدورة لاحقة، أو في حالات نادرة، قد تُلغى الدورة. [ 106 ]
لا يعني هذا أن القصة لا يمكن توسيعها. يجب على الفرق التعامل مع المعلومات الجديدة، والتي قد تُضيف مهامًا إضافية للقصة. إذا حالت المعلومات الجديدة دون إتمام القصة خلال الدورة الحالية، فيجب نقلها إلى دورة لاحقة. مع ذلك، ينبغي إعطاؤها الأولوية على باقي القصص، لأن المعلومات الجديدة قد تكون غيّرت من ترتيب أولويات القصة الأصلي.
نقص دعم الرعاة
غالبًا ما يُطبَّق تطوير البرمجيات الرشيقة كجهدٍ شعبيٍّ في المؤسسات من قِبَل فرق تطوير البرمجيات التي تسعى إلى تحسين عمليات التطوير وضمان الاتساق في دورة حياة تطوير البرمجيات. وبسبب غياب دعم الجهات الراعية، قد تواجه هذه الفرق صعوباتٍ ومقاومةً من الشركاء التجاريين وفرق التطوير الأخرى والإدارة. إضافةً إلى ذلك، قد تعاني هذه الفرق من نقص التمويل والموارد الكافية. [ 107 ] وهذا يزيد من احتمالية الفشل. [ 108 ]
التدريب غير الكافي
وجدت دراسة استقصائية أجرتها شركة VersionOne أن المستجيبين أشاروا إلى عدم كفاية التدريب باعتباره السبب الأكثر أهمية لفشل عمليات التنفيذ الرشيقة [ 109 ].
لم يتم شغل دور مالك المنتج بشكل صحيح
يتحمل مالك المنتج مسؤولية تمثيل الشركة في عملية التطوير، وغالبًا ما يكون هذا الدور هو الأكثر تطلبًا. [ 110 ]
من الأخطاء الشائعة إسناد دور مالك المنتج إلى أحد أعضاء فريق التطوير. هذا يُجبر الفريق على اتخاذ قراراته الخاصة بشأن تحديد الأولويات دون تلقي أي ملاحظات حقيقية من فريق العمل. فيحاولون حل مشكلات العمل داخليًا أو يؤخرون العمل باللجوء إلى مصادر خارجية للحصول على التوجيه. غالبًا ما يؤدي هذا إلى تشتيت الانتباه وانهيار التعاون. [ 111 ]
الفرق ليست مركزة
يتطلب تطوير البرمجيات الرشيقة من الفرق الوفاء بالتزامات المنتج، مما يعني ضرورة تركيزهم على العمل الخاص بهذا المنتج فقط. ومع ذلك، غالبًا ما يُتوقع من أعضاء الفريق الذين يبدو أن لديهم طاقة فائضة القيام بأعمال أخرى، مما يُصعّب عليهم المساهمة في إنجاز العمل الذي التزم به فريقهم. [ 112 ]
التحضير/التخطيط المفرط
قد تقع الفرق في فخ إضاعة الكثير من الوقت في التحضير والتخطيط. وهذا فخ شائع لدى الفرق الأقل خبرة في تطوير البرمجيات الرشيقة، حيث تشعر هذه الفرق بأنها ملزمة بفهم وتحديد جميع متطلبات المستخدم بشكل كامل. ينبغي أن تكون الفرق مستعدة للمضي قدمًا فقط في المهام التي تثق بها، ثم خلال دورة التطوير، تستمر في اكتشاف وتجهيز العمل للدورات اللاحقة (وهو ما يُعرف غالبًا بتحسين أو صقل قائمة مهام التطوير).
حل المشكلات في الاجتماع اليومي
ينبغي أن يكون الاجتماع اليومي السريع اجتماعًا مركزًا وفي الوقت المناسب، حيث يتبادل جميع أعضاء الفريق المعلومات. وإذا ما تم التطرق إلى حل المشكلات، فغالبًا ما يقتصر ذلك على أعضاء محددين من الفريق، وقد لا يكون ذلك الاستخدام الأمثل لوقت الفريق بأكمله. إذا انغمس الفريق في حل المشكلات أثناء الاجتماع اليومي السريع، فينبغي تأجيل ذلك إلى حين مناقشة فريق فرعي، وعادةً ما يكون ذلك مباشرةً بعد انتهاء الاجتماع. [ 113 ]
توزيع المهام
من بين الفوائد المرجوة من تطوير البرمجيات الرشيقة تمكين الفريق من اتخاذ القرارات، لكونهم الأقرب إلى المشكلة. إضافةً إلى ذلك، ينبغي عليهم اتخاذ القرارات في أقرب وقت ممكن من مرحلة التنفيذ، للاستفادة من المعلومات المتاحة في الوقت المناسب. إذا تم تكليف أعضاء الفريق بمهام من قِبل آخرين أو في وقت مبكر جدًا من العملية، فقد تُفقد فوائد اتخاذ القرارات الموضعية وفي الوقت المناسب. [ 114 ]
يُقيّد تكليف أعضاء الفريق بمهام محددة أدوارهم (على سبيل المثال، يجب على العضو "أ" القيام بأعمال قاعدة البيانات دائمًا)، مما يحدّ من فرص التدريب المتبادل. [ 114 ] ويمكن لأعضاء الفريق أنفسهم اختيار القيام بمهام تُنمّي قدراتهم وتُتيح لهم فرصًا للتدريب المتبادل.
قائد فريق سكروم كمساهم
في إطار عمل سكروم، الذي يدّعي التوافق مع قيم ومبادئ أجايل، يضطلع قائد سكروم بدور مسؤول عن ضمان اتباع عملية سكروم وتوجيه فريق سكروم خلالها. ومن الأخطاء الشائعة أن يتصرف قائد سكروم كمساهم. مع أن إطار عمل سكروم لا يمنع ذلك، إلا أنه يجب على قائد سكروم التأكد من امتلاكه القدرة على القيام بدور قائد سكروم أولاً، وليس العمل على مهام التطوير. فدور قائد سكروم هو تيسير العملية وليس إنشاء المنتج. [ 115 ]
قد يؤدي تكليف قائد فريق سكروم بمهام متعددة إلى تشتت انتباهه بشكل كبير، مما يعيق إنتاجيته. إضافةً إلى ذلك، ولأن قائد فريق سكروم مسؤول عن إزالة العقبات التي تحول دون تقدم الفريق، فإن الفائدة المرجوة من إنجاز المهام الفردية قد لا تفوق العقبات المؤجلة بسبب نقص الموارد. [ 116 ]
نقص أتمتة الاختبار
نظراً لطبيعة التطوير الرشيق التكرارية، غالباً ما تكون هناك حاجة إلى جولات متعددة من الاختبار. يساعد الاختبار الآلي على تقليل تأثير تكرار اختبارات الوحدة والتكامل والانحدار، ويُتيح للمطورين والمختبرين التركيز على أعمال ذات قيمة أعلى. [ 117 ]
يدعم أتمتة الاختبار أيضًا إعادة هيكلة الكود المستمرة التي تتطلبها عملية تطوير البرمجيات التكرارية. إن تمكين المطور من تشغيل الاختبارات بسرعة للتأكد من أن إعادة الهيكلة لم تُغير وظائف التطبيق قد يُقلل من عبء العمل ويزيد من الثقة بأن جهود التنظيف لم تُدخل عيوبًا جديدة.
السماح بتراكم الديون التقنية
قد يؤدي التركيز على تقديم وظائف جديدة إلى زيادة الديون التقنية . يجب على الفريق تخصيص وقت لمعالجة العيوب وإعادة هيكلة الكود. تعيق الديون التقنية قدرات التخطيط من خلال زيادة حجم العمل غير المجدول، حيث أن عيوب الإنتاج تشتت انتباه الفريق عن إحراز المزيد من التقدم. [ 118 ]
مع تطور النظام، يصبح من المهم إعادة هيكلته . [ 119 ] بمرور الوقت، يؤدي نقص الصيانة المستمرة إلى زيادة العيوب وتكاليف التطوير. [ 118 ]
محاولة القيام بالكثير في دورة واحدة
من المفاهيم الخاطئة الشائعة أن تطوير البرمجيات الرشيق يسمح بالتغيير المستمر، إلا أن قائمة مهام التكرار هي اتفاق على الأعمال التي يمكن إنجازها خلال كل تكرار. [ 120 ] يؤدي وجود الكثير من الأعمال قيد التنفيذ إلى أوجه قصور مثل تبديل السياق وتراكم المهام. [ 121 ] يجب على الفريق تجنب الشعور بالضغط لقبول أعمال إضافية. [ 122 ]
وقت محدد، وموارد، ونطاق، وجودة ثابتة
يُحدد تطوير البرمجيات الرشيقة الوقت (مدة التكرار)، والجودة، والموارد بشكل مثالي مسبقًا (مع أن الحفاظ على موارد ثابتة قد يكون صعبًا إذا انشغل المطورون كثيرًا بمعالجة أعطال الإنتاج)، بينما يظل نطاق التطوير متغيرًا. غالبًا ما يضغط العميل أو مالك المنتج لتحديد نطاق ثابت لكل تكرار. مع ذلك، ينبغي على الفرق التريث قبل الالتزام بالوقت والموارد والنطاق المحدد مسبقًا (المعروف بمثلث إدارة المشروع ). قد تؤدي محاولات توسيع نطاق التطوير الرشيق، بما يتجاوز الوقت والموارد المحددة، إلى انخفاض الجودة. [ 123 ]
الإرهاق الوظيفي للمطورين
نظراً للوتيرة المركزة والطبيعة المستمرة لممارسات أجايل، يزداد خطر الإرهاق بين أعضاء فريق التسليم. [ 124 ]
الإدارة الرشيقة
إدارة المشاريع الرشيقة هي عملية تطوير تكرارية، حيث يتم جمع الملاحظات باستمرار من المستخدمين وأصحاب المصلحة لخلق تجربة مستخدم مثالية. يمكن استخدام طرق مختلفة لتنفيذ عملية رشيقة، منها سكروم ، والبرمجة المتطرفة ، ولين ، وكانبان . [ 125 ] يُطلق مصطلح الإدارة الرشيقة على أسلوب تكراري تراكمي لإدارة أنشطة التصميم والبناء في مجالات الهندسة وتكنولوجيا المعلومات وغيرها من مجالات الأعمال، بهدف توفير تطوير منتجات أو خدمات جديدة بطريقة مرنة وتفاعلية للغاية، استنادًا إلى المبادئ الواردة في بيان تطوير البرمجيات الرشيقة . [ 126 ] تساعد مقاييس إدارة المشاريع الرشيقة على تقليل الارتباك، وتحديد نقاط الضعف، وقياس أداء الفريق طوال دورة التطوير. أما مرونة سلسلة التوريد فهي قدرة سلسلة التوريد على التعامل مع عدم اليقين والتقلبات في العرض والطلب. يمكن لسلسلة التوريد الرشيقة زيادة طاقتها وتقليلها بسرعة، ما يسمح لها بالتكيف مع طلبات العملاء المتغيرة باستمرار. وأخيرًا، المرونة الاستراتيجية هي قدرة المؤسسة على تغيير مسار عملها مع تطور بيئتها. يكمن مفتاح المرونة الاستراتيجية في التعرف على التغيرات الخارجية في وقت مبكر بما فيه الكفاية وتخصيص الموارد للتكيف مع هذه البيئات المتغيرة. [ 125 ]
قد تُسمى تقنيات Agile X أيضًا بإدارة المشاريع المتطرفة . وهي شكلٌ مُعدَّل من دورة حياة التطوير التكرارية [ 127 ] حيث تُقدَّم المُخرَجات على مراحل. ويكمن الفرق الرئيسي بين التطوير الرشيق والتطوير التكراري في أن أساليب التطوير الرشيق تُنجز أجزاءً صغيرة من المُخرَجات في كل دورة تسليم (تكرار) [ 128 ] ، بينما تُطوِّر أساليب التطوير التكرارية مجموعة المُخرَجات بأكملها بمرور الوقت، وتُنجزها قرب نهاية المشروع. وقد طُوِّرت كلتا الطريقتين، التكرارية والرشيقية، كرد فعلٍ على عقباتٍ مُختلفة ظهرت في أشكال تنظيم المشاريع الأكثر تسلسلًا. فعلى سبيل المثال، مع ازدياد تعقيد المشاريع التقنية، يميل المستخدمون النهائيون إلى مواجهة صعوبة في تحديد المتطلبات طويلة الأجل دون القدرة على رؤية نماذج أولية مُتطورة. أما المشاريع التي تُطوَّر على شكل تكرارات، فتُتيح جمع الملاحظات باستمرار للمساعدة في تحسين تلك المتطلبات.
توفر الإدارة الرشيقة إطار عمل بسيطًا يُعزز التواصل والتأمل في الأعمال السابقة بين أعضاء الفريق . [ 129 ] عادةً ما تمر الفرق التي كانت تستخدم منهجية التخطيط التقليدية (الشلالية) ثم تبنت منهجية التطوير الرشيقة بمرحلة تحول، وغالبًا ما تستعين بمدربين متخصصين في الإدارة الرشيقة لتوجيهها خلال هذه المرحلة بسلاسة أكبر. يوجد نمطان رئيسيان لتدريب الإدارة الرشيقة: التدريب القائم على الدفع والتدريب القائم على السحب. يشير "نظام الدفع" إلى التقدير المسبق للمهام التي يمكن إنجازها خلال دورة تطوير (دفع العمل)، كما هو الحال في منهجية سكروم؛ بينما يشير "نظام السحب" إلى بيئة لا تُنفذ فيها المهام إلا عند توفر الموارد. [ 130 ] وقد تم توظيف مناهج الإدارة الرشيقة وتكييفها لتناسب قطاعي الأعمال والحكومة. فعلى سبيل المثال، تستخدم الوكالة الأمريكية للتنمية الدولية (USAID) داخل الحكومة الفيدرالية للولايات المتحدة نهج إدارة المشاريع التعاونية الذي يركز على دمج استراتيجيات التعاون والتعلم والتكيف ( CLA) لتكرار البرامج وتكييفها. [ 131 ]
تم ذكر أساليب إدارة المشاريع الرشيقة في دليل إدارة المشاريع ( دليل PMBOK الإصدار السادس ) ضمن تعريف دورة حياة تطوير المنتج :
تتضمن دورة حياة المشروع عادةً مرحلةً واحدةً أو أكثر مرتبطةً بتطوير المنتج أو الخدمة أو النتيجة. تُسمى هذه المراحل بدورة حياة التطوير (...) دورات الحياة التكيفية هي دورات مرنة، أو تكرارية، أو تراكمية. يتم تحديد النطاق التفصيلي واعتماده قبل بدء كل تكرار. تُعرف دورات الحياة التكيفية أيضًا بدورات الحياة المرنة أو دورات الحياة القائمة على التغيير. [ 132 ]
تطبيقات خارج نطاق تطوير البرمجيات
بحسب جان لوب ريشيه (باحث في معهد ESSEC للابتكار الاستراتيجي والخدمات)، "يمكن الاستفادة من هذا النهج بفعالية في المنتجات غير البرمجية وفي إدارة المشاريع عمومًا، لا سيما في مجالات الابتكار وعدم اليقين". والنتيجة هي منتج أو مشروع يلبي احتياجات العملاء الحالية على أفضل وجه، ويتم تقديمه بأقل التكاليف والهدر والوقت، مما يمكّن الشركات من تحقيق مكاسب مالية أسرع من الطرق التقليدية. [ 133 ]
استُخدمت أساليب تطوير البرمجيات الرشيقة على نطاق واسع في تطوير المنتجات البرمجية، ويستفيد بعضها من خصائص معينة للبرمجيات، مثل تقنيات الكائنات . [ 134 ] ومع ذلك، يمكن تطبيق هذه التقنيات على تطوير منتجات غير برمجية، مثل أجهزة الحاسوب والأجهزة الطبية والأغذية والملابس والموسيقى. [ 135 ] كما استُخدمت أساليب تطوير البرمجيات الرشيقة في عمليات نشر وترحيل البنية التحتية لتكنولوجيا المعلومات غير التطويرية . ووجدت بعض المبادئ الأوسع نطاقًا لتطوير البرمجيات الرشيقة تطبيقات في الإدارة العامة [ 136 ] (مثل الاستراتيجية والحوكمة والمخاطر والتمويل) تحت مسمى مرونة الأعمال أو إدارة الأعمال الرشيقة. وتم اعتماد منهجيات البرمجيات الرشيقة أيضًا في عملية هندسة التعلم ، وهي عملية تكرارية تعتمد على البيانات وتُطبق التصميم المتمحور حول الإنسان واتخاذ القرارات بناءً على البيانات لدعم المتعلمين وتطويرهم. [ 137 ]
يمكن تطبيق نماذج تطوير البرمجيات الرشيقة في مجالات أخرى من الحياة، مثل تربية الأطفال. ولعل نجاحها في تنمية الطفل يرتكز على بعض مبادئ الإدارة الأساسية: التواصل، والتكيف، والوعي. في محاضرة له على منصة TED ، شارك بروس فيلر تجربته في تطبيق نماذج رشيقة أساسية على إدارة شؤون المنزل وتربية الأطفال. [ 138 ]
نقد
أُشير إلى أن ممارسات التطوير الرشيقة قد تكون غير فعّالة في المؤسسات الكبيرة وأنواع معينة من التطوير. [ 139 ] ترى العديد من المؤسسات أن منهجيات تطوير البرمجيات الرشيقة متطرفة للغاية، وتتبنى نهجًا هجينًا [ 140 ] يجمع بين عناصر تطوير البرمجيات الرشيقة والنهج القائم على التخطيط. [ 141 ] تحاول بعض الأساليب، مثل أسلوب تطوير الأنظمة الديناميكية (DSDM)، تطبيق ذلك بطريقة منضبطة، دون التضحية بالمبادئ الأساسية.
كما تعرض التوسع في تبني ممارسات إدارة المشاريع الرشيقة لانتقادات باعتبارها موضة إدارية تصف ببساطة الممارسات الجيدة الموجودة بمصطلحات جديدة، وتروج لعقلية "مقاس واحد يناسب الجميع" تجاه استراتيجيات التطوير، وتركز بشكل خاطئ على المنهجية على حساب النتائج. [ 142 ]
نظّم أليستير كوكبيرن احتفالًا بالذكرى العاشرة لبيان تطوير البرمجيات الرشيقة في سنو بيرد، يوتا، في 12 فبراير 2011، حيث جمع أكثر من 30 شخصًا ممن شاركوا في الاجتماع الأصلي وما تلاه. وتمّ جمع قائمة تضمّ حوالي 20 موضوعًا شائكًا ("قضايا/مواضيع غير قابلة للنقاش" في مجال تطوير البرمجيات الرشيقة)، بما في ذلك جوانب مثل: التحالفات، والإخفاقات، والقيود في ممارسات تطوير البرمجيات الرشيقة وسياقها (الأسباب المحتملة: المصالح التجارية، وفصلها عن سياقها، وعدم وجود طريقة واضحة لتحقيق التقدم بناءً على الإخفاق، ومحدودية الأدلة الموضوعية، والتحيزات المعرفية، والمغالطات المنطقية)، والسياسة، والثقافة. [ 143 ] كما كتب فيليب كروشتن :
إنّ حركة أجايل، من بعض النواحي، أشبه بمراهق: شديد الوعي بذاته، يُدقّق في مظهره باستمرار، لا يتقبّل النقد إلا نادرًا، لا يهتم إلا بالتواجد مع أقرانه، يرفض كل حكمة من الماضي رفضًا قاطعًا لمجرد أنها من الماضي، يتبنّى الصيحات والمصطلحات الجديدة، وأحيانًا يكون متغطرسًا ومتعجرفًا. لكنني لا أشكّ في أنها ستنضج أكثر، وتصبح أكثر انفتاحًا على العالم الخارجي، وأكثر تأملًا، وبالتالي، أكثر فعالية.
— فيليب كروشتن [ 143 ]
ربما كان لـ"البيان" أثر سلبي على إدارة التعليم العالي وقيادته، إذ اقترح على الإداريين استبدال العمليات التقليدية البطيئة والقائمة على التداول بعمليات أكثر "مرونة". ونادراً ما لاقى هذا المفهوم قبولاً بين أعضاء هيئة التدريس بالجامعات. [ 144 ]
من الانتقادات الأخرى أن الإدارة الرشيقة وممارسات الإدارة التقليدية تتعارض في كثير من الأحيان. ومن الانتقادات الشائعة لهذه الممارسة أن الوقت المستغرق في تعلمها وتطبيقها مكلف للغاية، على الرغم من فوائدها المحتملة. ويتطلب الانتقال من الإدارة التقليدية إلى الإدارة الرشيقة التزامًا تامًا بالمنهج الرشيق، وتعهدًا راسخًا من جميع أفراد المؤسسة بإتمام العملية بنجاح. ومن الأمثلة على ذلك: تفاوت النتائج في مختلف أقسام المؤسسة، وكثرة التغييرات التي يصعب على الموظفين التعامل معها، وانعدام الضمانات في نهاية عملية التحول. [ 145 ]
انظر أيضاً
- الفشل السريع (في مجال الأعمال) ، وهو موضوع ذو صلة في إدارة الأعمال
- كانبان
- القيادة الرشيقة
- العقود المرنة
مراجع
- ↑ "ما هي منهجية أجايل؟" . تحالف أجايل . 29 يونيو 2015. تم الاطلاع عليه بتاريخ 16 يوليو 2024 .
- كينت بيك ؛ جيمس غرينينغ؛ روبرت سي. مارتن ؛ مايك بيدل؛ جيم هايسميث ؛ ستيف ميلور ؛ آري فان بينيكوم؛ أندرو هانت ؛ كين شوابر ؛ أليستير كوكبيرن ؛ رون جيفريز ؛ جيف ساذرلاند؛ وارد كانينغهام ؛ جون كيرن؛ ديف توماس ؛ مارتن فاولر ؛ برايان ماريك (2001). "بيان تطوير البرمجيات الرشيقة" . تحالف أجايل . تم الاطلاع عليه بتاريخ 14 يونيو 2010 .
- 1 2 لارمان، كريج (2004). التطوير الرشيق والتكراري: دليل المدير . أديسون-ويسلي. ص 27. ISBN 978-0-13-111155-4.
- ↑ رالي (2010). "الرشاقة بحرف "أ" كبير مقابل الرشاقة بحرف "أ" صغير"تمت أرشفة هذا النص من المصدر الأصلي في 5 يناير 2016. تم الاطلاع عليه في 9 سبتمبر 2015 .
- ↑ كولير 2011 .
- ↑ "ما هو تطوير البرمجيات الرشيق؟" . تحالف الرشاقة. 8 يونيو 2013. تم الاطلاع عليه في 4 أبريل 2015 .
- ↑ ديبا، توري؛ دينغسوير، تورغير (1 أغسطس 2008). "دراسات تجريبية لتطوير البرمجيات الرشيقة: مراجعة منهجية". تكنولوجيا المعلومات والبرمجيات . 50 ( 9-10 ): 833-859 . doi : 10.1016/j.infsof.2008.01.006 . ISSN 0950-5849 . S2CID 2244031 .
- ↑ لي، غوانهو؛ شيا، ويدونغ (2010). "نحو منهجية رشيقة: تحليل متكامل للبيانات الميدانية الكمية والنوعية حول مرونة تطوير البرمجيات". مجلة نظم المعلومات الإدارية الفصلية . 34 (1): 87-114 . doi : 10.2307/20721416 . JSTOR 20721416. S2CID 26477249 .
- ↑ كرول، ج.؛ ريتشاردسون، إ.؛ بريكلادنيكي، ر.؛ أودي، ج. ل. (2018). "الأدلة التجريبية في تطوير البرمجيات وفقًا لمنهجية "اتبع الشمس": دراسة مسحية منهجية" . تكنولوجيا المعلومات والبرمجيات . 93 : 30-44 . doi : 10.1016/j.infsof.2017.08.011 . hdl : 10344/6233 .
- ↑ جيرالد م. واينبرغ ، كما ورد في لارمان وباسيلي 2003 ، الصفحات 47-56 : "كنا نتبع أسلوب التطوير التدريجي منذ عام 1957 في لوس أنجلوس، تحت إشراف بيرني ديمسديل في شركة خدمات آي بي إم . كان زميلًا لجون فون نيومان ، لذا ربما تعلمه هناك، أو اعتبره أمرًا طبيعيًا تمامًا. أتذكر هيرب جاكوبس (بشكل أساسي، على الرغم من مشاركتنا جميعًا) وهو يطور محاكاة ضخمة لشركة موتورولا، حيث كانت التقنية المستخدمة، على حد علمي... كنا جميعًا، على حد ما أتذكر، نعتقد أن اتباع منهجية الشلال في مشروع ضخم أمرٌ غبي، أو على الأقل يعكس جهلًا بالواقع. أعتقد أن وصف منهجية الشلال جعلنا ندرك أننا كنا نقوم بشيء آخر، شيء لم يُسمَّ سوى "تطوير البرمجيات " .
- ↑ "إدارة المشاريع التطورية (الصفحة الأصلية، أرشيف خارجي)" . جيلب. مؤرشف من الأصل في 27 مارس 2016. تم الاطلاع عليه في 30 أبريل 2017 .
- ↑ "إدارة المشاريع التطورية (صفحة جديدة)" . graphMetrix . Gilb . تم الاطلاع عليه في 30 أبريل 2017 .
- ↑ إدموندز، إي. أ. (1974). "عملية لتطوير البرمجيات للمستخدمين غير التقنيين كنظام تكيفي". الأنظمة العامة . 19 : 215-218 .
- ↑ جيلب، توم (1 أبريل 1981). "التطور التطوري". ملاحظات هندسة البرمجيات ACM SIGSOFT . 6 (2): 17. doi : 10.1145/1010865.1010868 . S2CID 33902347 .
- ↑ سواميداس، ب.م.، محرر (2000)، "تنظيم المشاريع الضخمة" ، موسوعة إدارة الإنتاج والتصنيع ، بوسطن، ماساتشوستس: سبرينغر الولايات المتحدة، ص 261-262 ، doi : 10.1007/1-4020-0612-8_400 ، ISBN 978-1-4020-0612-8تم الاطلاع عليه بتاريخ 22 يونيو 2022
- ↑ مارتن، جيمس (1991). التطوير السريع للتطبيقات . ماكميلان. ISBN 978-0-02-376775-3.
- ↑ كير، جيمس م.؛ هنتر، ريتشارد (1993). داخل RAD: كيفية بناء نظام كامل الوظائف في 90 يومًا أو أقل . ماكجرو هيل. ص 3. ISBN 978-0-07-034223-1.
- ↑ معهد إياكوكا (1991). "استراتيجية مؤسسات التصنيع في القرن الحادي والعشرين: رؤية تقودها الصناعة". معهد إياكوكا، جامعة ليهاي، بيت لحم، بنسلفانيا.
- ↑ بريسلي، أ.، ج. ميلز ود. لايلز (1995). "التصنيع الرشيق في مجال الطيران والفضاء". نيبكون إيست 1995، بوسطن.
- ↑ سانشيز، لويس (نوفمبر 2010). "مراجعة لأنظمة التصنيع الرشيقة" . المجلة الدولية لبحوث الإنتاج (39(16):3561-3600).
- ↑ أندرسون، ديفيد (2005). "إعلان الترابط" . مؤرشف من الأصل في 27 يناير 2018. تم الاطلاع عليه في 4 أكتوبر 2018 .
- ↑ ماكدونالد، كينت (1 نوفمبر 2016). "كيف يمكنك مساعدة تحالف أجايل على مساعدتك" . مدونة تحالف أجايل . تم الاطلاع عليه في 4 يوليو 2017 .
- ↑ "دراسة بيان أجايل" . شركة أمبيسوفت . تم الاطلاع عليه بتاريخ 6 أبريل 2011 .
- ↑ جيم هايسميث (2001). "التاريخ: بيان أجايل" . agilemanifesto.org.
- كينت بيك ؛ جيمس غرينينغ؛ روبرت سي. مارتن ؛ مايك بيدل؛ جيم هايسميث ؛ ستيف ميلور ؛ آري فان بينيكوم؛ أندرو هانت ؛ كين شوابر ؛ أليستير كوكبيرن ؛ رون جيفريز ؛ جيف ساذرلاند ؛ وارد كانينغهام ؛ جون كيرن؛ ديف توماس ؛ مارتن فاولر ؛ برايان ماريك (2001). "المبادئ الكامنة وراء بيان أجايل" . تحالف أجايل. مؤرشف من الأصل في 14 يونيو 2010. تم الاسترجاع في 6 يونيو 2010 .
- ↑ معهد إدارة المشاريع 2021 ، 2.3.3 مناهج التطوير.
- ↑ روبين 2013 .
- ↑ معهد إدارة المشاريع 2021 ، §3.12 تمكين التغيير لتحقيق الحالة المستقبلية المنشودة.
- ↑ موران، أ. (2014). إدارة المخاطر الرشيقة . دار نشر سبرينغر. ISBN 978-3319050072.
- ↑ بيك، كينت (1999). "احتضان التغيير باستخدام البرمجة المتطرفة". مجلة الكمبيوتر . 32 (10): 70-77 . رمز Bibcode : 1999Compr..32j..70B . doi : 10.1109/2.796139 .
- ↑ ميرجل، إينيس (يوليو 2016). "إدارة الابتكار الرشيق في الحكومة: أجندة بحثية" . مجلة المعلومات الحكومية الفصلية . 33 (3): 516-523 . doi : 10.1016/j.giq.2016.07.004 .
- ↑ برويس، ديبورا هارتمان (13 أكتوبر 2006). "دراسة: فرق العمل المتواجدة في نفس المكان مقابل بيئة المكاتب المنفصلة" . InfoQ . تم الاطلاع عليه بتاريخ 23 أكتوبر 2018 .
- ↑ كوكبيرن، أليستير (2007). "تطوير البرمجيات الرشيقة: اللعبة التعاونية" . www.pearson.com ( الطبعة الثانية). أديسون-ويسلي بروفيشنال . تم الاطلاع عليه بتاريخ 23 أكتوبر 2018 .
- ↑ "الإدارة المتحولة | البحث" .
- ↑ جاين، باريتا؛ شارما، أرون؛ أهوجا، لاكشمي (أغسطس 2018). "أثر عملية تطوير البرمجيات الرشيقة على جودة منتج البرمجيات". المؤتمر الدولي السابع لعام 2018 حول الموثوقية وتقنيات المعلومات والاتصالات والتحسين (الاتجاهات والتوجهات المستقبلية) (ICRITO) . نويدا، الهند: IEEE. الصفحات 812-815 . doi : 10.1109/ICRITO.2018.8748529 . ISBN 978-1-5386-4692-2. S2CID 195775457 .
- ↑ معهد إدارة المشاريع 2021 ، §2.7.3.2 مشعات المعلومات.
- ↑ أمبلر، سكوت (12 أبريل 2002). النمذجة الرشيقة: ممارسات فعالة للبرمجة المتطرفة والعملية الموحدة . جون وايلي وأولاده. الصفحات 12، 164، 363. ISBN 978-0-471-20282-0.
- ↑ فاسيلياوسكاس، فيداس (2014). "تطوير ممارسات إدارة مهام وفرق المشاريع الرشيقة" . إيلين. مؤرشف من الأصل في 15 سبتمبر 2014. تم الاطلاع عليه في 15 سبتمبر 2014 .
- ↑ جيفريز، رون؛ أندرسون، آن؛ هندريكسون، تشيت (2001). البرمجة المتطرفة المثبتة . أديسون-ويسلي. ص 72-147 . ISBN 978-0201-70842-4.
- ↑ ليزا كريسبين؛ جانيت غريغوري (2009). اختبار البرمجيات الرشيقة: دليل عملي للمختبرين وفرق البرمجيات الرشيقة . أديسون-ويسلي.
- ↑ ميتشل، إيان (2016). التطوير الرشيق عمليًا . دار تاماري للنشر. ص 11. ISBN 978-1-908552-49-5.
- ↑ لارمان، كريج (2004). التطوير الرشيق والتكراري: دليل المدير . أديسون-ويسلي. ص 27. ISBN 978-0-13-111155-4.
- ↑ بوهم، ب .؛ ر. تيرنر (2004). الموازنة بين الرشاقة والانضباط: دليل للمتحيرين . بوسطن، ماساتشوستس: أديسون-ويسلي. ISBN 978-0-321-18612-6.الملحق أ، الصفحات 165-194
- ↑ لارمان، كريج (2004). "الفصل 11: نصائح عملية" . التطوير الرشيق والتكراري: دليل المدير . أديسون-ويسلي بروفيشنال. ص 253. ISBN 9780131111554تم الاطلاع عليه بتاريخ 14 أكتوبر 2013 .
- ↑ سليجر، ميشيل؛ برودريك، ستاسيا (2008). جسر مدير مشروع البرمجيات إلى المرونة . أديسون-ويسلي. ص 46. ISBN 978-0-321-50275-9.
- 1 2 بوهم، ب .؛ ر. تيرنر (2004). موازنة الرشاقة والانضباط: دليل للمتحيرين . بوسطن، ماساتشوستس: أديسون-ويسلي. ص 55-57 . ISBN 978-0-321-18612-6.
- ↑ راكيتين، ستيفن ر. (2001). "بيان يثير السخرية: رسالة قارئ إلى المحرر بقلم ستيفن ر. راكيتين". مجلة IEEE Computer . 34 (12): 4. doi : 10.1109/MC.2001.10095 . S2CID 221106984.
المقال المعنون "تطوير البرمجيات الرشيقة: أعمال الابتكار" ... هو محاولة أخرى لتقويض تخصص هندسة البرمجيات ... نريد أن نقضي كل وقتنا في كتابة الأكواد. تذكروا، المبرمجون الحقيقيون لا يكتبون التوثيق.
- 1 2 سكوت أمبلر (16 أبريل 2023). "التوثيق الرشيق/المرن: استراتيجيات لتطوير البرمجيات الرشيقة" .
- ↑ سكوت أمبلر. "نماذج ووثائق جيدة بما يكفي بالكاد: أفضل الممارسات في منهجية أجايل" . مؤرشف من الأصل في 8 أكتوبر 2014. تم الاطلاع عليه في 24 يناير 2014 .
- ↑ جيفري وايزمان (18 يوليو 2007). "هل تتطلب منهجيات أجايل توثيقًا؟" . InfoQ.نقلاً عن كوبر، إيان (6 يوليو 2007). "إشارات متقطعة: منهجية أجايل والتوثيق" . WordPress.com .
- 1 2 3 أبراهامسون بي، سالو أو، رونكاينين جي، وارستا جي (2002). أساليب تطوير البرمجيات الرشيقة: المراجعة والتحليل (PDF) (تقرير فني). فت . 478.
- ↑ "دليل الممارسات الرشيقة" . تحالف الرشاقة. مؤرشف من الأصل في 9 فبراير 2014.
- ↑ بو، كين (2011). تطوير البرمجيات الرشيق الموجه باختبارات القبول: برمجيات أفضل من خلال التعاون . أديسون-ويسلي. ISBN 978-0321714084.
- ↑ أدزيك، جويكو. (2009) سد فجوة التواصل: المواصفات من خلال المثال واختبار القبول الرشيق ، نيوري المحدودة،
- ↑ أدزيتش، جويكو (2011). المواصفات من خلال المثال: كيف تُقدّم الفرق الناجحة البرمجيات المناسبة . مانينغ. ISBN 978-0-321-27865-4.
- ↑ تشيلمسكي، ديفيد، ديف أستلز، زاك دينيس، أسلاك هيليسوي، برايان هيلمكامب، ودان نورث. كتاب RSpec: التطوير الموجه بالسلوك باستخدام RSpec وCucumber وFriends. مكتبة براغماتيك.
- ↑ "التصميم القائم على الأمثلة" . تم الاطلاع عليه بتاريخ 15 أبريل 2013 .
- ↑ "تطوير البرمجيات القائم على اختبار القصة" (ملف PDF) . تم الاطلاع عليه بتاريخ 15 أبريل 2013 .
- ↑ الصفحة الرئيسية للنمذجة الرشيقة (AM)، ممارسات فعالة للنمذجة والتوثيق
- ↑ أتلاسين. "قائمة مهام المنتج: قائمة مهامك النهائية" . أتلاسين . تم الاطلاع عليه بتاريخ 19 ديسمبر 2021 .
- 1 2 "ما هي قائمة مهام المنتج؟" . Scrum.org . تم الاطلاع عليه بتاريخ 19 ديسمبر 2021 .
- 1 2 3 "الممارسات الأساسية في منهجية أجايل: المتطلبات ذات الأولوية" . agilemodeling.com . تم الاطلاع عليه بتاريخ 19 ديسمبر 2021 .
- ↑ "العنصر: قائمة عناصر العمل" . www.utm.mx. تم الاطلاع عليه بتاريخ 19 ديسمبر 2021 .
- ↑ "منتجات | Digitaliseringsdirektoratet" . مؤرشفة من الأصلي في 10 أغسطس 2020 . تم الاسترجاع في 15 نوفمبر 2021 .
- ↑ "دراسة حالة: التنمية القائمة على السلوك - الجزء الأول" . تم الاطلاع عليه بتاريخ 7 مايو 2026 .
- ↑ فاولر، مارتن (1 مايو 2006). "التكامل المستمر" . تم الاطلاع عليه في 9 يناير 2014 .
- ↑ بوتش، جرادي (1991). التصميم الموجه للكائنات: مع تطبيقات . بنجامين كامينغز . ص 209. ISBN 9780805300918تم الاطلاع عليه بتاريخ 18 أغسطس 2014 .
- ↑ بيك، ك. (1999). "احتضان التغيير باستخدام البرمجة المتطرفة". مجلة الكمبيوتر . 32 (10): 70-77 . doi : 10.1109/2.796139 . ISSN 0018-9162 .
- ↑ كراجيفسكي، إل جيه و إل بي ريتزمان. 2005. إدارة العمليات: العمليات وسلاسل القيمة. بيرسون إديوكيشن، أبر سادل ريفر.
- ↑ "اجتماعات الوقوف اليومية (STUM): 7 أفضل الممارسات" . joinassembly.com . تم الاطلاع عليه بتاريخ 25 يوليو 2026 .
- 1 2 أيدين، إم إن؛ هارمسن، إف؛ سلوتين؛ ستاغوي، آر إيه (2004). "منهجية تطوير نظم المعلومات الرشيقة قيد الاستخدام". المجلة التركية للهندسة الكهربائية . 12 (2): 127-138 .
- ↑ موريس، ديفيد (2015). مفارقة التحول الرشيق: لماذا يُعيق السعي الحثيث نحو الرشاقة المؤسسات من أن تصبح رشيقة حقًا . نيوزيلندا: جامعة أوكلاند. doi : 10.13140/RG.2.2.32698.08640 .
- ↑ أبراهامسون، ب.، وارستا، ج.، سيبونين، م. ت.، ورونكاينين، ج. (2003). اتجاهات جديدة في منهجيات أجايل: تحليل مقارن. وقائع مؤتمر ICSE'03 ، 244-254
- ↑ ميراخورلي، م.؛ راد، أ.ك.؛ شمس، ف.؛ بازوكي، م.؛ ميراخورلي، أ. (2008). "تقنية RDP: ممارسة لتخصيص XP". وقائع ورشة العمل الدولية لعام 2008 حول التدقيق في الممارسات الرشيقة أو المواجهة في حظيرة الرشاقة (APOS '08) . ACM. ص 23-32 . doi : 10.1145/1370143.1370149 . ISBN 978-1-60558-021-0. S2CID 9528636 .
- ↑ شوابر، ك (2006) سكروم صعب ومُعطِّل.
- ↑ فود، ب (2016) قصة LeSS. الكلمة الختامية. سكروم أستراليا، ملبورن. أبريل 2016.
- ↑ لاغستيدت، أ.، ودالبرغ، ت. (2018). فهم ندرة اختيار طريقة ISD - العقلانية المحدودة والغباء الوظيفي. وقائع مؤتمر PACIS 2018.154. https://aisel.aisnet.org/pacis2018/154
- ↑ بارك، جيه إس، ماكماهون، بي إي، ومايبورغ، بي. (2016). سكروم مدعوم بالجوهر. ملاحظات هندسة البرمجيات ACM SIGSOFT، 41(1)، ص 1-8.
- ↑ بيك، ك. (1999). شرح البرمجة المتطرفة: تقبّل التغيير . بوسطن، ماساتشوستس: أديسون-ويسلي. ISBN 978-0-321-27865-4.
- ↑ إيفانز، إيان. "التسليم الرشيق في شركة بريتيش تيليكوم" . تم الاطلاع عليه بتاريخ 21 فبراير 2011 .
- 1 2 دبليو سكوت أمبلر (2006) سوبر سايز مي في مجلة دكتور دوب، 15 فبراير 2006.
- ↑ شاف، آر جيه (2007). مؤتمر أجيليتي إكس إل لأنظمة وتكنولوجيا البرمجيات 2007. مؤرشف في 13 مارس 2016 على موقع Wayback Machine ، تامبا، فلوريدا.
- ↑ "تجسير المسافة" . Sdmagazine.com . تم الاطلاع عليه في 1 فبراير 2011 .
- ↑ فاولر، مارتن. "استخدام عملية تطوير البرمجيات الرشيقة مع التطوير الخارجي" . Martinfowler.com . تم الاطلاع عليه بتاريخ 6 يونيو 2010 .
- ↑ ورشة عمل العمليات الرشيقة II: إدارة مشاريع رشيقة متعددة ومتزامنة. واشنطن: OOPSLA 2002
- ↑ كولي، أوسين؛ وانغ، شياوفينغ؛ ريتشاردسون، إيتا (2010). "منهجيات تطوير البرمجيات الرشيقة/المرنة في البيئات الخاضعة للتنظيم - أحدث ما توصل إليه العلم". في: أبراهامسون، بيكا؛ أوزا، نيلاي (محرران). برمجيات وأنظمة المؤسسات الرشيقة . سلسلة محاضرات في معالجة معلومات الأعمال. المجلد 65. الصفحات 31-36 . doi : 10.1007/978-3-642-16416-3_4 . hdl : 10344/683 . ISBN 978-3-642-16415-6.
- ↑ ماكهيو، مارتن؛ مكافري، فيرغال؛ كودي، غاريت (4 نوفمبر 2014). "تطبيق منهجية أجايل في مؤسسة برمجيات للأجهزة الطبية". في: ميتاسيناس، أنتاناس؛ روت، تيري؛ أوكونور، روري ف.؛ وآخرون (محررون). تحسين عمليات البرمجيات وتحديد القدرات . مجلة الاتصالات في علوم الحاسوب والمعلومات. المجلد 477. الصفحات 190-201 . doi : 10.1007/978-3-319-13036-1_17 . ISBN 978-3-319-13035-4.
- ↑ وانغ، يانغ؛ رمضاني، ياسمين؛ فاغنر، ستيفان (29 نوفمبر 2017). "دراسة استكشافية حول تطبيق عملية تطوير سكروم للأنظمة الحساسة للسلامة". تحسين عملية تطوير البرمجيات الموجهة نحو المنتج . سلسلة محاضرات في علوم الحاسوب. المجلد 10611. الصفحات 324-340 . arXiv : 1703.05375 . Bibcode : 2017arXiv170305375W . doi : 10.1007/978-3-319-69926-4_23 . ISBN 9783319699257. S2CID 4585465 .
- ^ "SafeScrum - سينتيف" . سينتيف.لا . تم الاسترجاع في 26 مارس 2019 .
- ^ Thor Myklebust، Tor Stålhane، Geir Kjetil Hanssen، Tormod Wien و Børge Haugset: Scrum والوثائق ومعيار البرمجيات IEC 61508-3:2010، http://www.sintef.no/globalassets/ec-61508-documentation-and-safescrum-psam12.pdf أرشفة 27 يونيو 2022 على آلة Wayback
- ↑ فيتزجيرالد، ب.؛ ستول، ك.-ج.؛ أوسوليفان، ر.؛ أوبراين، د. (مايو 2013). "توسيع نطاق منهجيات أجايل لتشمل البيئات الخاضعة للتنظيم: دراسة حالة صناعية". المؤتمر الدولي الخامس والثلاثون لهندسة البرمجيات (ICSE) لعام 2013. الصفحات 863-872 . doi : 10.1109/ICSE.2013.6606635 . hdl : 10344/3055 . ISBN 978-1-4673-3076-3. S2CID 192403 .
- ↑ بيك، كينت (2000). شرح البرمجة المتطرفة . أديسون-ويسلي. الصفحات 1-24 . ISBN 978-0201616415.
- ↑ داتا، سوبهاجيت (2006). "مؤشر قياس المرونة: مقياس لمفترق طرق منهجيات تطوير البرمجيات". وقائع المؤتمر الإقليمي السنوي الرابع والأربعين لجمعية ACM-SE، ص 271. doi : 10.1145/1185448.1185509 . ISBN 1595933158.
- ↑ بيتر لابو؛ هنري سي تي أندرو. "تقييم المرونة" (ملف PDF) . مؤرشف من الأصل (ملف PDF) في 15 سبتمبر 2009. تم الاطلاع عليه في 6 يونيو 2010 .
- ↑ جو ليتل (2 ديسمبر 2007). "اختبار نوكيا، اختبار خاص بمنهجية سكروم" . Agileconsortium.blogspot.com . تم الاطلاع عليه في 6 يونيو 2010 .
- ↑ مارك سيوفيرت؛ مايبيرغ، السويد. "اختبار كارلسكرونا، اختبار عام لتبني منهجية أجايل" . Mayberg.se . تاريخ الاسترجاع: 5 أبريل 2014 .
- ↑ "ما مدى مرونتك؟ (أجرِ هذا الاختبار المكون من 42 نقطة)" . allaboutagile.com/. مؤرشف من الأصل في 5 مايو 2014. تم الاطلاع عليه في 3 أبريل 2014 .
- ↑ "نتائج استطلاع منهجيات أجايل" (ملف PDF) . شركة شاين تكنولوجيز. يناير 2003. مؤرشف من الأصل (ملف PDF) بتاريخ 21 أغسطس 2010. تم الاطلاع عليه بتاريخ 3 يونيو 2010.
أفاد 95% من المشاركين بعدم وجود أي تأثير أو بانخفاض في التكاليف
... أفاد 93% بتحسن الإنتاجية أو تحسنها بشكل ملحوظ
... أفاد 88% بتحسن الجودة أو تحسنها بشكل ملحوظ
... أفاد 83% بتحسن رضا الموظفين أو تحسنه بشكل ملحوظ
- ↑ "تقرير حالة منهجية أجايل لعام 2013: لماذا أجايل؟" . stateofagile.com. 27 يناير 2014. مؤرشف من الأصل في 28 أغسطس 2014. تم الاطلاع عليه في 13 أغسطس 2014 .
- ↑ الوضع الراهن للمنهجيات الرشيقة ( مؤرشف في 18 مارس 2018 على موقع Wayback Machine) ، الدراسة الثانية حول نجاح المنهجيات الرشيقة وأشكال استخدامها. تم الاطلاع عليها في 1 يوليو 2015.
- ↑ أمبلر، سكوت (3 أغسطس 2006). " استطلاع رأي يقول: منهجية أجايل فعّالة عمليًا" . دكتور دوبس . تم الاطلاع عليه في 3 يونيو 2010.
أشار 6% فقط إلى انخفاض إنتاجيتهم
... لم يُبلغ 34% من المشاركين عن أي تغيير في الإنتاجية، بينما أبلغ 60% عن زيادة في الإنتاجية
... وأفاد 66% بأن الجودة أعلى
... وأبلغت 58% من المؤسسات عن تحسن في مستوى الرضا، في حين أبلغ 3% فقط عن انخفاضه.
- ↑ "الإجابة على سؤال "أين الدليل على نجاح منهجيات أجايل؟"" . Agilemodeling.com. ١٩ يناير ٢٠٠٧. تم الاطلاع عليه في ٢ أبريل ٢٠١٠ .
- ↑ شور وواردن 2008 ، ص 47
- ↑ بيك، كينت (2000). شرح البرمجة المتطرفة . أديسون-ويسلي. ص 48-49 . ISBN 978-0201616415.
- ↑ راوس، مارغريت. "تعريف سبرينت (تطوير البرمجيات)" . searchsoftwarequality.techtarget.com . تم الاطلاع عليه بتاريخ 2 أكتوبر 2015 .
- ↑ غولدشتاين، إيلان (11 أكتوبر 2011). "مشاكل دورات التطوير السريعة - عندما تتحول دورات التطوير السريعة إلى دورات بطيئة للغاية" . www.axisagile.com.au . تم الاطلاع عليه بتاريخ 8 يونيو 2014 .
- ↑ "أدوار المشروع وتوزيع المسؤوليات" . agile-only.com . تم الاطلاع عليه بتاريخ 15 يونيو 2014 .
- ↑ بورن، ليندا. "ماذا يفعل راعي المشروع حقًا؟" . blogs.pmi.org . مؤرشف من الأصل في 7 يونيو 2014. تم الاطلاع عليه في 8 يونيو 2014 .
- ↑ «التقرير التاسع عن حالة منهجية أجايل» . استطلاع مراحل أجايل . فيرجن ون. مؤرشف من الأصل بتاريخ ١٢ يناير ٢٠١٥. تم الاطلاع عليه بتاريخ ٨ يونيو ٢٠١٤ .
- ↑ سيمز، كريس؛ جونسون، هيلاري لويز (15 فبراير 2011). عناصر سكروم ( نسخة كيندل). دايمكسيكون. ص 73.
- ↑ روثمان، جوانا روثمان (25 أغسطس 2011). "عندما لا يكون لديك مالك منتج على الإطلاق" . www.jrothman.com . تم الاطلاع عليه بتاريخ 8 يونيو 2014 .
- ↑ فوكس، أليسا (8 أبريل 2014). "العمل ضمن فرق أجايل متعددة" . techwhirl.com/ . تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- ↑ "اجتماع سكروم اليومي" . www.mountaingoatsoftware.com . تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- 1-2 مايو، روبرت. "التخطيط الفعال لدورة التطوير السريعة" . www.agileexecutives.org . مؤرشف من الأصل في 28 يونيو 2014. تم الاطلاع عليه في 14 يونيو 2014 .
- ↑ بيرتشوك، ستيف. "المهمة ممكنة: مدير سكروم والمساهم التقني" . www.agileconnection.com . تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- ↑ "كيفية تطبيق منهجية سكروم الرشيقة" . تم الاطلاع عليه بتاريخ 4 يناير 2022 .
- ↑ نامتا، راجنيش. "أفكار حول أتمتة الاختبارات في منهجية أجايل" . www.infoq.com . مؤرشف من الأصل بتاريخ 18 أغسطس 2014. تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- 1 2 باند، تسفي (22 مارس 2014). "الدين التقني + أكتوبر الأحمر" . تسفي باند . مؤرشف من الأصل في 14 يوليو 2014. تم الاطلاع عليه في 8 يونيو 2014 .
- ↑ شور، جيمس. "فن التطوير الرشيق: إعادة هيكلة الكود" . www.jamesshore.com . تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- ↑ "الخطوة 4: تخطيط دورة التطوير (المهام)" . www.allaboutagile.com . مؤرشف من الأصل بتاريخ 29 يونيو 2014. تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- ↑ جورج، كلير (3 مارس 2014). "لماذا يُعدّ الحدّ من العمل قيد الإنجاز أمرًا مهمًا" . leankit.com . تم الاطلاع عليه في 14 يونيو 2014 .
- ↑ "اجتماع تخطيط دورة التطوير السريعة" . www.mountaingoatsoftware.com . تم الاطلاع عليه بتاريخ 14 يونيو 2014 .
- ↑ ماكميلان، كيث (13 مايو 2010). "الوقت والموارد والنطاق... والجودة" . www.adeptechllc.com . تم الاطلاع عليه بتاريخ 15 يونيو 2014 .
- ↑ "دراسة حديثة حول قيود منهجية أجايل" . وقائع علوم الحاسوب . 78 : 291-297 . يناير 2016. doi : 10.1016/j.procs.2016.02.056 .
- 1 2 "دعوة المشتريات إلى منهجية أجايل، ماذا تعني؟" . 1 نوفمبر 2019.
- ↑ موران، آلان (2015). إدارة منهجية أجايل: الاستراتيجية، والتنفيذ، والتنظيم، والأفراد . سبرينغر. ISBN 978-3-319-16262-1.
- ↑ "ما هي دورة الحياة الأنسب لمشروعك؟" . PMHut . 22 أكتوبر 2008. تم الاطلاع عليه بتاريخ 23 أكتوبر 2009 .
- ↑ "إدارة المشاريع الرشيقة" . الإصدار الأول . مؤرشف من الأصل في 9 يونيو 2015. تم الاطلاع عليه في 1 يونيو 2015 .
- ↑ "ما هي الإدارة الرشيقة؟" . Project Laneways. مؤرشف من الأصل في 2 يونيو 2015. تم الاطلاع عليه في 1 يونيو 2015 .
- ↑ بنسون، جيم؛ دي ماريا باري، تونيان (2011). كانبان الشخصي: رسم خرائط العمل، وتوجيه الحياة ( الطبعة الأولى). سياتل، واشنطن: مطبعة مودوس كوبراندي. ص 38. ISBN 978-1-4538-0226-7.
- ↑ الوكالة الأمريكية للتنمية الدولية. "السياسة التشغيلية لدورة برنامج الفصل 201 من برنامج ADS". مؤرشف في 23 أكتوبر 2019 على موقع Wayback Machine . تم الاطلاع عليه في 19 أبريل 2017.
- ↑ معهد إدارة المشاريع ، دليل إلى مجموعة معارف إدارة المشاريع (دليل PMBOK)، الطبعة السادسة
- ^ ريشيت، جان لوب (2013). الابتكار رشيق . حالات وأبحاث تطبيقية، عدد 31. ESSEC-ISIS. رقم ISBN 978-2-36456-091-8
- ↑ سميث، بريستون ج (2007). تطوير المنتجات المرنة . جوسي-باس. ص 25. ISBN 978-0-7879-9584-3.
- ↑ نيوتن لي (2014). "الوصول إلى قوائم بيلبورد: إنتاج الموسيقى كتطوير برمجيات رشيق"، ديجيتال دافنشي: الحواسيب في الموسيقىدار نشر سبرينغر للعلوم والأعمال. رقم ISBN 978-1-4939-0535-5.
- ↑ موران، آلان (2015). إدارة منهجية أجايل: الاستراتيجية، والتنفيذ، والتنظيم، والأفراد . دار نشر سبرينغر. رقم ISBN 978-3-319-16262-1.
- ↑ باريت، م.؛ جوديل، ج. (2022)، "أدوات التطوير الرشيق والمرن"، مجموعة أدوات هندسة التعلم ، روتليدج، ص 269-278 ، doi : 10.4324/9781003276579-16 ، ISBN 978-1-003-27657-9
- ↑ "البرمجة الرشيقة - لعائلتك" .
- ↑ لارمان، كريج؛ باس فود (13 أغسطس 2009). أهم عشرة عوائق تنظيمية أمام تبني منهجية أجايل على نطاق واسع . إنفورم آي تي.
- ↑ "مقدمة في إدارة المشاريع الهجينة" . ركن التعاون . 20 يوليو 2016. مؤرشف من الأصل في 7 يناير 2020. تم الاطلاع عليه في 16 يناير 2018 .
- ↑ بارلو، جوردان ب.؛ جاستن سكوت جيبوني؛ مارك جيفري كيث؛ ديفيد دبليو. ويلسون؛ رايان إم. شوتزلر؛ بول بنجامين لوري؛ أنتوني فانس (2011). "نظرة عامة وإرشادات حول التطوير الرشيق في المؤسسات الكبيرة" . مجلة اتصالات جمعية نظم المعلومات . 29 (1): 25-44 . doi : 10.17705/1CAIS.02902 .
- ↑ كوبرسميث، كوبي (4 يوليو 2011). "المنهجية الرشيقة مجرد موضة عابرة" .
- 1 2 كروشتن، فيليب (20 يونيو 2011). "أزمة المراهقة في منهجية أجايل؟" . إنفو كيو.
- ↑ ريتشارد أوتز، "ضد لغة الإدارة"، كرونيكل للتعليم العالي ، 24 يونيو 2020.
- ↑ كوهن، مايك (2015). النجاح مع منهجية أجايل . بيرسون. الصفحات 5-10 . ISBN 978-0-321-57936-2.
للمزيد من القراءة
- أبراهامسون، ب.؛ سالو، أ.؛ رونكاينن، ج.؛ وارستا، ج. (2002). "أساليب تطوير البرمجيات الرشيقة: مراجعة وتحليل" . منشورات VTT. 478. مؤرشف من الأصل في 7 سبتمبر 2011. تم الاطلاع عليه في 20 فبراير 2012 .
- أشمور، سوندرا؛ رونيان، كريستين (2014). مقدمة في منهجيات أجايل . أديسون-ويسلي. ISBN 978-0321929563.
- بارلو، جوردان ب.؛ جاستن سكوت جيبوني؛ مارك جيفري كيث؛ ديفيد و. ويلسون؛ رايان م. شوتزلر؛ بول بنجامين لوري؛ أنتوني فانس (2011). "نظرة عامة وإرشادات حول التطوير الرشيق في المؤسسات الكبيرة" . مجلة اتصالات جمعية نظم المعلومات . 29 (1): 25-44 . doi : 10.17705/1CAIS.02902 .
- كوهين، د.؛ ليندفال، م.؛ كوستا، ب. (2004). "مقدمة في منهجيات أجايل" . في: زيلكوفيتز، مارفن (محرر). التطورات في هندسة البرمجيات . سلسلة التطورات في الحوسبة. المجلد 62. دار النشر الأكاديمية. الصفحات 1-66 . ISBN 978-0-08-047190-7.
- كولير، كين دبليو. (2011). التحليلات الرشيقة: منهج قائم على القيمة في ذكاء الأعمال وتخزين البيانات . بيرسون للتعليم. ISBN 9780321669544ما
هو الفريق ذاتي التنظيم؟
- دينجسوير، تورجير؛ ديبا، تور؛ مو، نيلز بريدي (2010). تطوير البرمجيات الرشيقة: البحث الحالي والاتجاهات المستقبلية . سبرينغر. رقم ISBN 978-3-642-12575-1.
- فاولر، مارتن (2001). "هل مات التصميم؟" . في: سوتشي، جيانكارلو؛ ماركيزي، ميشيل (محرران). دراسة البرمجة المتطرفة . أديسون-ويسلي. ص 3-18 . ISBN 978-0-201-71040-3.
- لارمان، كريغ؛ باسيلي، فيكتور ر. (يونيو 2003). "التطوير التكراري والتراكمي: تاريخ موجز". مجلة IEEE Computer . 36 (3): 47-56 . Bibcode : 2003Compr..36f..47L . doi : 10.1109/MC.2003.1204375 . S2CID 9240477 .
- كاساني، ميشيل؛ بينيتو، روبرت؛ مايفيلد، كاثلين م.؛ نورثرن، كارلتون (8 سبتمبر 2013). "دليل تطبيق منهجية أجايل في اقتناء تكنولوجيا المعلومات بوزارة الدفاع" . مؤسسة ميتري.
- موران، آلان (2015). إدارة منهجية أجايل: الاستراتيجية، والتنفيذ، والتنظيم، والأفراد . سبرينغر. ISBN 978-3-319-16262-1.
- Riehle, Dirk. "مقارنة بين أنظمة القيم لتطوير البرمجيات التكيفية والبرمجة المتطرفة: كيف يمكن للمنهجيات أن تتعلم من بعضها البعض" .في سوتشي ومارشيزي 2001
- روبين، كينيث (2013). أساسيات سكروم: دليل عملي لأكثر عمليات أجايل شيوعًا . أديسون-ويسلي. ISBN 978-0-13-704329-3.
- شور، جيمس؛ واردن، شين (2008). فن التطوير الرشيق . دار نشر أورايلي ميديا. رقم ISBN 978-0-596-52767-9.
- معهد إدارة المشاريع (2021). دليل إلى مجموعة معارف إدارة المشاريع (دليل PMBOK) . معهد إدارة المشاريع ( الطبعة السابعة). نيوتاون سكوير، بنسلفانيا. ISBN 978-1-62825-664-2.
{{cite book}}: CS1 maint: موقع الناشر مفقود ( رابط ) - ستيفنز، م.؛ روزنبرغ، د. (2003). إعادة هيكلة البرمجة المتطرفة: الحجة ضد البرمجة المتطرفة . دار نشر أبريس. رقم ISBN 978-1-59059-096-6.
- سواميداس، بي إم، محرر (2000)، "تنظيم المشاريع الضخمة" ، موسوعة إدارة الإنتاج والتصنيع ، بوسطن، ماساتشوستس: سبرينغر الولايات المتحدة، ص 261-262 ، doi : 10.1007/1-4020-0612-8_400 ، ISBN 978-1-4020-0612-8تم الاطلاع عليه بتاريخ 22 يونيو 2022
- تاكيوتشي، هيروتاكا؛ نوناكا، إيكوجيرو (1 يناير 1986). "لعبة تطوير المنتجات الجديدة" . مجلة هارفارد للأعمال . الرقم الدولي الموحد للدوريات 0017-8012 . تاريخ الاسترجاع: 25 يوليو 2021 .
- "مقدمة في إدارة المشاريع الهجينة" . ركن التعاون . 20 يوليو 2016. مؤرشف من الأصل في 7 يناير 2020. تم الاطلاع عليه في 16 يناير 2018 .
روابط خارجية
- بيان أجايل
- مسرد المصطلحات الرشيقة لتحالف أجايل
- المنهجية الجديدة - وصف مارتن فاولر لخلفية منهجيات أجايل
- تطوير البرمجيات الرشيقة
- إدارة مشاريع البرمجيات
- تطوير البرمجيات
- هندسة البرمجيات
- فلسفات تطوير البرمجيات