البرمجة المتطرفة. البرمجة المتطرفة - منهجية XP

23.03.2019

إرسال عملك الجيد في قاعدة المعرفة أمر بسيط. استخدم النموذج أدناه

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

تم النشر على http://www.allbest.ru/

محتوى

مقدمة
1. ما هو XP؟
3.1 التقنيات الأساسيةXP
4. المزايا والعيوب
5. تاريخ الاستخدام
خاتمة

مقدمة

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

غالبًا ما يتم تقديم XP كمجموعة من التقنيات، لكن XP بحد ذاته ليس خط النهاية. ليست هناك حاجة لممارسة وتطوير الموارد البشرية بشكل أفضل وأفضل من أجل الحصول على النجمة الذهبية التي طال انتظارها في نهاية هذه العملية. على العكس من ذلك، XP هو خط البداية. يطرح XP السؤال التالي: "ما مدى الحد الأدنى من جهودنا حتى نتمكن من الاستمرار في إنتاج برامج عالية الجودة؟"

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

1. ما هو XP؟

القصوىمالكتانبرنامجممتنقل(إنجليزي) أقصى برمجة, XP) هي إحدى منهجيات تطوير البرمجيات المرنة. مؤلفو المنهجية هم كينت بيك، وارد كننغهام، مارتن فاولر وآخرون.

XP عبارة عن طريقة مبسطة وفعالة ومرنة ويمكن التنبؤ بها وسليمة علميًا وممتعة للغاية ومنخفضة المخاطر لتطوير البرامج. تختلف الموارد البشرية عن الطرق الأخرى في النواحي التالية:

ومن خلال استخدام دورات تطوير قصيرة للغاية، يقدم XP تعليقات سريعة وحقيقية ومستمرة.

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

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

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

يعتمد XP على التواصل الشفهي والاختبارات وكود المصدر. تُستخدم هذه الأدوات الثلاث لتبادل المعلومات حول بنية النظام وسلوكه.

يعتمد XP على عملية تصميم متطورة تستمر طالما أن النظام نفسه موجود.

يعتمد XP على التفاعل الوثيق بين المبرمجين ذوي المهارات والقدرات الأكثر شيوعًا.

يعتمد XP على تقنيات تلبي الغرائز قصيرة المدى للمبرمجين الفرديين والمصالح طويلة المدى للمشروع بأكمله.

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

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

2. أين تبدأ البرمجة المتطرفة؟

أين تبدأ البرمجة المتطرفة؟ من منطلق أن الوضع النموذجي لمطور البرامج المحلي يلزمه بتقليل تكاليف التطوير قدر الإمكان. ولهذا من الضروري التعاون بشكل مكثف مع العميل، وفهم اهتماماته، وفي النهاية، القيام بما يريده بالضبط: لا أكثر ولا أقل.

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

تقدم شركة Extreme Programming حلاً جاهزًا: اجعل كل شيء بسيطًا قدر الإمكان، أو احتفظ بالعميل لنفسك أو ابق مع العميل، ودعه يراقب عملية التطوير بشكل نشط، ورحب بالتغيير - والنجاح مضمون تقريبًا.

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

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

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

3. تقنيات XP

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

المبادئ الأساسية لتطوير البرمجيات الحية منصوص عليها في بيان التطوير المباشر، الذي ظهر في عام 2000.

· يعد الأشخاص المشاركون في المشروع وتواصلهم أكثر أهمية من العمليات والأدوات.

· برنامج العمل أهم من التوثيق الشامل.

· التعاون مع العميل أهم من مناقشة تفاصيل العقد.

· العمل من خلال التغييرات أكثر أهمية من الالتزام بالخطط.

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

تسمح الأساليب "المباشرة" للمطورين بتركيز معظم جهودهم على مهام التطوير وتلبية احتياجات المستخدم الحقيقية. يتيح لك عدم وجود أكوام من المستندات والحاجة إلى الاحتفاظ بها في حالة متماسكة الاستجابة بسرعة وكفاءة أكبر للتغيرات في المتطلبات وفي البيئة التي سيتعين على البرنامج المستقبلي أن يعمل فيها.

ومع ذلك، لدى XP مخطط عملية التطوير الخاص بها (على الرغم من أن الفهم المستخدم على نطاق واسع لـ "عملية التطوير" كمخطط إجراءات صارم إلى حد ما يتعارض مع فكرة التطوير "الحيوي")، كما هو موضح في الشكل 1 .

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

· يعيشتخطيط (تخطيطلعبة)

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

أرز.1 مخطط سير العمل XP

· متكرريتغيرالخامسالإصدارات (صغيرإطلاق)

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

· استعارة (استعارة) أنظمة

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

الهندسة المعمارية هي فكرة عن مكونات النظام وكيفية ترابطها. يستخدم المطورون الهندسة المعمارية لفهم مكان إضافة بعض الوظائف الجديدة في النظام، وما الذي سيتفاعل معه بعض المكونات الجديدة.

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

· بسيطتصميمحلول (بسيطتصميم)

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

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

· تطويرعلىأساساختبارات (امتحان- تحركهاتطوير)

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

يركز XP بشكل خاص على نوعين من الاختبارات:

اختبار الوحدة؛

ب- اختبار القبول.

برامج البرمجة المتطرفة

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

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

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

· ثابتإعادة التدوير (إعادة بناء التعليمات البرمجية)

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

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

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

· برمجةفي باريس (زوجبرمجة)

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

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

· جماعيتملُّكشفرة (جماعيملكية)

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

من خلال منح كل مبرمج الحق في تغيير التعليمات البرمجية، فإننا نخاطر بالأخطاء التي يسببها المبرمجون الذين يعتقدون أنهم يعرفون ما يفعلونه ولكنهم لا يأخذون في الاعتبار تبعيات معينة. تعمل اختبارات UNIT المحددة جيدًا على حل هذه المشكلة: إذا أدت التبعيات غير المفحوصة إلى حدوث أخطاء، فسوف تفشل عملية التشغيل التالية لاختبارات UNIT.

· ثابتاندماج (مستمراندماج)

يتم تجميع النظام ويخضع لاختبار التكامل كلما كان ذلك ممكنًا، عدة مرات في اليوم، في كل مرة ينتهي فيها اثنان من المبرمجين من تنفيذ الوظيفة التالية.

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

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

· 40 ساعةعملأسبوع

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

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

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

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

· تضمينعميلالخامسفريق (على- موقععميل)

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

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

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

· الاستخدامشفرةكيفمرافقمجال الاتصالات

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

· يفتحعملفضاء (يفتحمساحة العمل)

يتواجد الفريق في غرفة واحدة فسيحة إلى حد ما لتسهيل التواصل وتمكين المناقشات الجماعية عند التخطيط واتخاذ القرارات الفنية المهمة.

· يتغيرقواعدبواسطةضروري (فقطقواعد)

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

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

3.1 تقنيات XP الأساسية

اثنا عشر تقنية أساسية للبرمجة المتطرفة (استنادًا إلى الطبعة الأولى من الكتاب أقصى برمجة شرح) يمكن دمجها في أربع مجموعات:

· دورة قصيرة تعليق(ردود الفعل على نطاق جيد)

o التطوير القائم على الاختبار

o لعبة التخطيط

o يكون العميل قريبًا دائمًا (الفريق بأكمله، العميل في الموقع)

س البرمجة الزوجية

عملية مستمرة وليست دفعة واحدة

o التكامل المستمر

o إعادة البناء (تحسين التصميم، إعادة البناء)

o الإصدارات الصغيرة المتكررة

· الفهم المشترك بين الجميع

o البساطة (تصميم بسيط)

o استعارة النظام

o ملكية الكود الجماعي أو أنماط التصميم المحددة (ملكية الأنماط الجماعية)

o معيار الترميز أو اصطلاحات الترميز

· رفاهية المبرمج:

o 40 ساعة عمل في الأسبوع (بوتيرة مستدامة، أربعون ساعة في الأسبوع)

لعبةالخامستخطيط

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

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

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

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

4. المزايا والعيوب

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

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

5. تاريخ الاستخدام

تم استخدام XP كمجموعة من التقنيات الموصوفة لأول مرة أثناء العمل في مشروع C3 (نظام تعويضات كرايسلر الشامل، تطوير نظام محاسبة استحقاقات الموظفين في دايملر كرايسلر). من بين المشاركين العشرين في هذا المشروع، نشر 5 (بما في ذلك المؤلفون الثلاثة الرئيسيون المذكورون أعلاه لـ XP) 3 كتب وعددًا كبيرًا من المقالات المخصصة لـ XP أثناء المشروع نفسه وبعده. توضح البيانات التالية المشكلات المتعلقة ببعض تقنيات XP عند تطبيقها على المشاريع المعقدة إلى حد ما.

بدأ المشروع في يناير 1995. منذ مارس 1996، بعد ضم كينت بيك، تم تشغيله باستخدام XP. وبحلول هذا الوقت، كانت قد تجاوزت بالفعل الميزانية وخطط التنفيذ المرحلي للوظائف. تم قطع فريق التطوير، وبعد حوالي ستة أشهر، تم تطوير المشروع بنجاح كبير. وفي أغسطس 1998، ظهر نموذج أولي يمكن أن يخدم حوالي 10000 موظف. كان من المتوقع أصلاً أن يكتمل المشروع في منتصف عام 1999 وسيتم استخدام البرنامج الناتج لإدارة المزايا لموظفي الشركة البالغ عددهم 87000 موظف. تم إيقافه في فبراير 2000 بعد 4 سنوات من تشغيل XP بسبب الفشل الكامل في تلبية الأطر الزمنية والميزانية. لم يتم استخدام البرنامج الذي تم إنشاؤه مطلقًا للتعامل مع بيانات أكثر من 10000 موظف، على الرغم من أنه ثبت أنه يمكنه التعامل مع بيانات 30000 موظف في الشركة. استقال الشخص الذي لعب دور العميل المتضمن في فريق المشروع بعد بضعة أشهر من هذا العمل، غير قادر على تحمل عبء العمل، ولم يحصل على بديل مناسب حتى نهاية المشروع.

خاتمة

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

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

تم النشر على موقع Allbest.ru

وثائق مماثلة

تحليل مراحل وميزات تطوير نموذج ARIS الأمثل والوظيفي - منتج برمجي من IDS Scheer لنمذجة العمليات التجارية للشركة. دراسة المفاهيم والمنهجيات والأساليب الأساسية للبرمجة المتطرفة.

تمت إضافة الاختبار في 06/04/2011

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

تمت إضافة العرض في 13/10/2013

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

تمت إضافة البرنامج التعليمي في 26/10/2013

مشكلة موثوقية البرمجيات ومؤشراتها وعوامل دعمها. طرق مراقبة عملية تطوير البرامج والتوثيق ومنع الأخطاء. مراحل عملية تصحيح أخطاء البرمجيات وتقنياتها برمجة منظمةومبدأ النمطية.

تمت إضافة العرض في 30/04/2014

رموز الآلة والمجمع. أولى لغات البرمجة عالية المستوى. لغة برمجة فورتران. مميزات وعيوب ALGOL. العلمية و برامج المحاسبة. المبادئ الأساسية التي تم اتباعها عند إنشاء لغة البرمجة الأساسية.

تمت إضافة الدورة التدريبية في 21/06/2014

مفهوم و الفرق الرئيسيتطوير البرمجيات الموزعة، مزاياها وعيوبها. الحل المفاهيميواختيار نوع التطوير. مميزات البرمجيات مفتوحة المصدر. فكرة وتطور المصادر المفتوحة.

تمت إضافة الدورة التدريبية في 14/12/2012

مفهوم دورة الحياةبرمجة. نوعان من الأنشطة المميزة في المشاريع الفنية: التصميم والإنتاج. المبادئ الأساسية لبيان أتباع المنهجيات المرنة. المبادئ الأساسيةالبرمجة المتطرفة.

تمت إضافة العرض بتاريخ 14/08/2013

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

تمت إضافة الدورة التدريبية في 28/02/2010

الآلات الحديثةتطوير البرمجيات لSUTP. اللغات العالميةبرمجة ومقارنتها مع أنظمة SCADA. تطوير البرمجيات باستخدام محولات القياس متعددة القنوات SH9327.

أطروحة، أضيفت في 13/07/2011

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

تقنيات XP الأساسية

اثنا عشر تقنية أساسية للبرمجة المتطرفة (استنادًا إلى الطبعة الأولى من الكتاب وأوضح البرمجة المتطرفة) يمكن دمجها في أربع مجموعات:

ردود فعل جيدة الحجم
- التطوير القائم على الاختبار
- لعبة التخطيط
- العميل قريب دائمًا (الفريق بأكمله، العميل في الموقع)
- برمجة الزوج
عملية مستمرة وليست دفعة واحدة
- التكامل المستمر
- إعادة البناء (تحسين التصميم، إعادة البناء)
- الإصدارات الصغيرة المتكررة
فهم مشترك بين الجميع
- البساطة (تصميم بسيط)
- استعارة النظام
- ملكية الكود الجماعي أو أنماط التصميم المحددة (ملكية الأنماط الجماعية)
- معيار الترميز أو اصطلاحات الترميز
رفاهية المبرمج:
- 40 ساعة عمل في الأسبوع (وتيرة مستدامة، أربعون ساعة في الأسبوع)

اختبارات

يركز XP بشكل خاص على نوعين من الاختبارات:

وحدة التجارب؛
اختبار القبول.

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

لعبة التخطيط

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

العميل موجود دائمًا

"العميل" في XP ليس هو من يدفع الفواتير، ولكن المستخدم النهائيمنتج برمجي. تنص XP على أنه يجب على العميل أن يكون على اتصال في جميع الأوقات وأن يكون متاحًا لطرح الأسئلة.

برمجة الزوج

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

التكامل المستمر

إعادة بناء التعليمات البرمجية

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

الإصدارات الصغيرة المتكررة

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

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

بساطة التصميم

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

استعارة النظام

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

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

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

معايير الترميز

يجب على جميع أعضاء الفريق الالتزام بمعايير الترميز المشتركة أثناء العمل. وبالتالي:

لا يضيع أعضاء الفريق وقتهم في جدالات غبية حول أشياء لا تؤثر في الواقع على سرعة العمل في المشروع؛
ويتم ضمان التنفيذ الفعال للممارسات الأخرى.

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

الملكية الجماعية

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

الأدب

كينت بيك: البرمجة المتطرفة- بيتر، 2002، ISBN 5-94723-032-1.
كينت بيك، مارتن فاولر: البرمجة المتطرفة: التخطيط- بيتر، 2003، ISBN 5-318-00111-4.
كينت بيك: البرمجة المتطرفة: التطوير القائم على الاختبار- بيتر، 2003، ISBN 5-8046-0051-6.
كين أوير، روي ميلر: "البرمجة المتطرفة: إعداد العملية من الخطوات الأولى إلى النهاية المريرة" - بيتر، 2003، ISBN 5-318-00132-7.

أنظر أيضا

روابط

وارد كننغهام ويكي - XP "المتطور".
XProgramming.com (الإنجليزية) - موقع رون جيفريز: مقالات وموارد حول XP والمواضيع ذات الصلة، ومراجعات الكتب.
البرمجة المتطرفة: مقدمة لطيفة (الإنجليزية) - "مقدمة لطيفة لنظام XP" بقلم دون ويلز.
MAXKIR.COM (بالروسية) - ترجمات مقالات للآباء المؤسسين والأيديولوجيين لـ XP
www.agiledev.ru (بالروسية) - موقع إلكتروني لطرق التطوير المرنة
TopCoder (الإنجليزية) - مسابقة البرمجة الرياضية
المكتبة الإلكترونية للكتب حول البرمجة المتطرفة (بالروسية)
البرمجة المتطرفة - الواقع والأساطير (بالروسية)
الاختبار في ضوء البرمجة المتطرفة. الجزء 1 (الروسية)
تكنولوجيا المعلومات وعلم النفس. العامل البشري في البرمجة الزوجية: لماذا لا يحصل الكثير من الناس على ما يريدون من تنفيذها؟ (الروسية)

تطوير البرمجيات
مشهور الأرقام
عملية
المفاهيم
الاتجاهات
عارضات ازياء تطوير
نماذج أخرى
آخر

مؤسسة ويكيميديا. 2010.

تعرف على معنى "البرمجة المتطرفة" في القواميس الأخرى:

البرمجة المتطرفة- إحدى منهجيات تطوير البرمجيات. المواضيع تكنولوجيا المعلوماتبشكل عام EN البرمجة المتطرفة XP ... دليل المترجم الفني

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

إدارة المشاريع المتطرفة (XPM) هي طريقة لإدارة المشاريع المعقدة للغاية أو غير المؤكدة. من الطرق التقليديةإدارة مشروع XPM مفتوحة ومرنة و... ... ويكيبيديا

المبادئ الأساسية لتطوير البرمجيات الحية منصوص عليها في بيان التطوير المباشر، الذي ظهر في عام 2000.

· يعد الأشخاص المشاركون في المشروع وتواصلهم أكثر أهمية من العمليات والأدوات.
· برنامج العمل أهم من التوثيق الشامل.
· التعاون مع العميل أهم من مناقشة تفاصيل العقد.
· العمل من خلال التغييرات أكثر أهمية من الالتزام بالخطط.

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

ومع ذلك، لدى XP مخطط عملية التطوير الخاص بها (على الرغم من أن الفهم المستخدم على نطاق واسع لـ "عملية التطوير" كمخطط إجراءات صارم إلى حد ما يتعارض مع فكرة التطوير "الحيوي")، كما هو موضح في الشكل 1 .

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

· يعيش تخطيط لعبة)

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

رسم بياني 1

· متكرر يتغير الإصدارات (صغيرة إطلاق)

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

· استعارة النظام

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

الهندسة المعمارية هي فكرة عن مكونات النظام وكيفية ترابطها. يستخدم المطورون الهندسة المعمارية لفهم مكان إضافة بعض الوظائف الجديدة في النظام، وما الذي سيتفاعل معه بعض المكونات الجديدة.

· بسيط تصميم الحلول (بسيطة تصميم)

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

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

· تطوير على أساس اختبار (يعتمد على الاختبار تطوير)

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

يركز XP بشكل خاص على نوعين من الاختبارات:

اختبار الوحدة؛

ب- اختبار القبول.

برامج البرمجة المتطرفة

· ثابت إعادة بناء التعليمات البرمجية

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

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

· برمجة أزواج برمجة)

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

· جماعي تملُّك كود ( جماعي ملكية)

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

· ثابت التكامل (مستمر اندماج)

· 40 ساعة عمل أسبوع

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

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

· تضمين عميل الخامس فريق (في الموقع عميل)

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

· الاستخدام شفرة كيف مرافق مجال الاتصالات

· يفتح عمل مساحة (مفتوحة مساحة العمل)

· يتغير قواعد بواسطة ضروري (فقط قواعد)

كما يتبين من التقنيات المستخدمة، تم تصميم XP للاستخدام ضمن فرق صغيرة (لا تزيد عن 10 مبرمجين)، وهو ما أكد عليه مؤلفو هذه التقنية. يؤدي حجم الفريق الأكبر إلى تدمير سهولة الاتصال اللازمة لتحقيق النجاح ويجعل من المستحيل تنفيذ العديد من التقنيات المذكورة.

مبرر اقتصادي شامل لجميع الإجراءات - يتم تنفيذ ما يحتاجه العميل فقط ولا يؤدي إلى عدم ربحية المشروع.

تشكيل البنية الأساسية في أقرب وقت ممكن.

باستخدام بنية المكونات.

النماذج الأولية والتطوير التدريجي والاختبار.

تقييمات منتظمة للوضع الحالي.

إدارة التغيير، التطوير المستمر للتغييرات من خارج المشروع.

ركز على إنشاء منتج يعمل في بيئة حقيقية.

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

تكييف العملية مع احتياجات المشروع.

البرمجة المتطرفة

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

المبادئ الأساسية لتطوير البرمجيات الحية منصوص عليها في بيان التطوير المباشر، الذي ظهر في عام 2000.

يعد الأشخاص المشاركون في المشروع وتواصلهم أكثر أهمية من العمليات والأدوات.

برنامج العمل أكثر أهمية من التوثيق الشامل.

التعاون مع العميل أهم من مناقشة تفاصيل العقد.

يعد العمل من خلال التغييرات أكثر أهمية من الالتزام بالخطط.

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

لعبة التخطيط المباشر

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

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

				امتحان
		يستخدم		سيناريوهات
			قصة جديدة
	متطلبات		يستخدم
	متطلبات		سرعة المشروع

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

حلول "رمي".

الشكل 15. مخطط تدفق العمل في XP.

تغييرات الإصدار المتكررة (الإصدارات الصغيرة)

استعارة النظام

حلول تصميم بسيطة

التطوير القائم على الاختبار(التطوير القائم على الاختبار)

إعادة الهيكلة المستمرة

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

برمجة الزوج

أولاً، يقدم النصيحة، ويأخذ في الاعتبار عواقب قرارات معينة، واختبارات جديدة، وحلول أقل مباشرة، ولكنها أكثر مرونة.

الملكية الجماعية للكود

في في أي وقت، يمكن لأي عضو في الفريق تغيير أي جزء من الكود. لا ينبغي لأحد أن يكون لديه مجال مسؤوليته الخاصة؛ الفريق بأكمله مسؤول عن جميع التعليمات البرمجية.

التكامل المستمر

40 ساعة عمل في الأسبوع

إدراج العميل في الفريق(العميل في الموقع)

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

استخدام الكود كوسيلة للتواصل

مساحة عمل مفتوحة

تغيير القواعد حسب الحاجة (القواعد فقط)

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

تم استخدام XP كمجموعة من التقنيات الموصوفة لأول مرة أثناء العمل في مشروع C3 (نظام تعويضات كرايسلر الشامل، تطوير نظام محاسبة الدفع

موظفي دايملر كرايسلر). من بين المشاركين العشرين في هذا المشروع، نشر 5 (بما في ذلك المؤلفون الثلاثة الرئيسيون المذكورون أعلاه لـ XP) 3 كتب وعددًا كبيرًا من المقالات المخصصة لـ XP أثناء المشروع نفسه وبعده. تم ذكر هذا المشروع مرارًا وتكرارًا في مصادر مختلفة كمثال على استخدام هذه التقنية. تم تجميع البيانات التالية من المقالات المذكورة، بدون أدلة قصصية، وتوضح المشكلات المتعلقة ببعض تقنيات XP عند تطبيقها على مشاريع معقدة إلى حد ما.

الأدب للمحاضرة 3

دبليو رويس. إدارة المشاريع البرمجية. م: لوري، 2002.

أ. جاكوبسون، ج. بوتش، ج. رامبو. عملية تطوير البرمجيات الموحدة. سانت بطرسبرغ: بيتر، 2002.

كرول، روح RUP. www-106.ibm.com/developerworks/rational/library/ المحتوى/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

ك.بيك. البرمجة المتطرفة. سانت بطرسبرغ: بيتر، 2002.

http://www.agilemanifesto.org/

ك. بيك، وآخرون. آل. كرايسلر تذهب إلى "التطرف". الحوسبة الموزعة، 10/1998.

أ. كوكبيرن. اختيار منهجية المشروع. IEEE للبرمجيات، 04/2000.

إل ويليامز، آر آر كيسلر، دبليو كننغهام، آر جيفريز. تعزيز حالة البرمجة الزوجية. برنامج آي إي إي إي 4/2000.

جي كيفر. البرمجة المتطرفة تعتبر ضارة لتطوير البرمجيات الموثوقة. تقرير أفوكا الفني، 2002.

متاح كما http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.

تعد البرمجة المتطرفة (XP) إحدى منهجيات تطوير البرمجيات المرنة. مؤلفو المنهجية هم كينت بيك، وارد كننغهام، مارتن فاولر وآخرون.

لعبة التخطيط

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

خطة الإصدار

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

تخطيط التكرار

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

اجتماع الوقوف

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

بساطة

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

نظام الاستعارات

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

العميل في موقع العمل

المشكلة الرئيسية في تطوير البرمجيات هي نقص معرفة المبرمجين في مجال الموضوع الذي يتم تطويره. لقد وجدت البرمجة المتطرفة طريقة للخروج من هذا الوضع. لا، هذا ليس تدريبًا داخليًا للمطورين في مؤسسة العميل - فلن يرغب في البرمجة. على العكس من ذلك، فهي مشاركة العميل في عملية التطوير.
هل يمكن للمبرمج، دون أن يفهم جوهر المشكلة بشكل كامل ودون أن يكون متخاطرًا، أن يخمن ما يريده العميل؟ الجواب واضح. أكثر بطريقة بسيطةللتغلب على هذا الإزعاج - وتعلمنا البرمجة المتطرفة العثور على أبسط الحلول - سيكون علينا طرح سؤال مباشر على العميل. تتطلب الأساليب الأكثر صرامة إجراء تحليل أولي شامل للمنطقة التي يجري تطويرها. في حالات معينةوهذا له ما يبرره، على الرغم من أنه أكثر تكلفة. تجربة حقيقيةيُظهر تشغيل المشاريع الدنيوية أنه من المستحيل جمع جميع المتطلبات مسبقًا. علاوة على ذلك، حتى لو افترضنا أن جميع المتطلبات موجودة هذه اللحظةعند تجميعها، سيظل هناك عنق الزجاجة واحد: البرامج، مثل كل شيء في الطبيعة، لا يتم إنشاؤها على الفور، وفي هذه الأثناء يمكن أن تتغير العمليات التجارية. وينبغي أن يؤخذ هذا في الاعتبار.
يشكك الكثيرون في إمكانية إشراك العميل في عملية التطوير. في الواقع، العملاء مختلفون. إذا لم يكن من الممكن جذب العميل أو ممثله، فمن المستحسن أحيانًا تعيين متخصص مؤقتًا في المجال الذي يتم تطويره. ستؤدي هذه الخطوة إلى تقليل الغموض في العمل وزيادة سرعة التطوير وتقريب المشروع مما يريد العميل الحصول عليه. يمكن أن يكون هذا مفيدا أيضا من الجانب المالي: بعد كل شيء، يكون راتب المبرمج في بعض الأحيان أعلى بكثير من راتب المتخصصين في الصناعات الأخرى.
قصة المستخدم. قصة المستخدم (تشبه قصة المستخدم) هي وصف لكيفية عمل النظام. تتم كتابة كل قصة مستخدم على بطاقة وتمثل جزءًا من وظائف النظام التي تعتبر منطقية من وجهة نظر العميل. النموذج عبارة عن فقرة أو فقرتين من النص تكون مفهومة للمستخدم (ليست تقنية للغاية).
قصة المستخدم كتبها العميل. وهي مشابهة لحالات استخدام النظام، ولكنها لا تقتصر على واجهة المستخدم. ولكل قصة يتم كتابة اختبارات وظيفية للتأكد من ذلك هذه القصةتم تنفيذها بشكل صحيح - وتسمى أيضًا اختبارات القبول.

الاختبار قبل بدء التطوير

الاختبار بمعناه الكلاسيكي هو إجراء ممل إلى حد ما. عادةً ما يقومون بتعيين مُختبر يقوم بشكل دوري بتنفيذ نفس الإجراءات وينتظر اليوم الذي يتم فيه نقله أخيرًا إلى منصب آخر أو تظهر فرصة تغيير الوظيفة.
في البرمجة المتطرفة، يكون دور الاختبار أكثر إثارة للاهتمام: الآن يأتي الاختبار أولاً، ثم الكود. كيفية اختبار شيء غير موجود بعد؟ الإجابة بسيطة ومبتذلة: اختبر أفكارك - ما الذي تتوقعه من أي برنامج أو وظيفة مستقبلية. سيسمح لك ذلك بفهم ما يتعين على المبرمجين القيام به بشكل أفضل والتحقق من وظيفة الكود بمجرد كتابته.
ولكن الاختبار قد لا يعمل أيضا. لذلك، اكتب اختبارا للاختبار؟ ومن ثم الاختبار للاختبار وهكذا إلى ما لا نهاية؟ مُطْلَقاً. سيحل اختبار الاختبار محل الكود. كيف ذلك؟ لكن انظر: تخيل أنك بحاجة إلى تثبيت الصمولة في منتصف المزلاج حتى لا يدور. ماذا يفعلون من أجل هذا؟ قم بربط الصامولة الثانية بالقرب من الأولى، بحيث تمنع كل صامولة المجاورة لها من الدوران. الأمر نفسه في البرمجة: الاختبار يختبر الكود، والكود يختبر الاختبار.
تظهر التجربة أن هذا النهج لا يبطئ التنمية فحسب، بل يسرع أيضا. بعد كل شيء، فإن معرفة ما يجب القيام به وحجم العمل المطلوب سيوفر الوقت من خلال رفض بيع العناصر التي لم يطالب بها أحد. هذه اللحظةتفاصيل.

برمجة الزوج

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

تغيير المواقف

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

ملكية الكود الجماعي

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

اتفاقية الترميز

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

التكامل المتكرر

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

أربعون ساعة عمل في الأسبوع

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

خاتمة

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

فهرس:

مقالات مماثلة