تحليل رشيق. الخرافات والواقع

أنا مقدمة

يجب أن يتم نقل كشك! لا يوجد موسم ، بحيث لا يقوم شخصان بشاندارة.
الخلط الآن مع المرحاض ، ثم مع المقصورة الشاطئ ...
(x / f ملامح الصيد الوطني)

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

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

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

II خلفية لظهور تقنيات تطوير منتجات البرمجيات

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

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

1. الخرافات والواقع حول الشلال

كما ذكرنا سابقًا في المقدمة ، تم اختيار Antagonism (عرض الهدى) لـ Agile (1) تقنية Waterfall ، والتي كانت في شكلها النقي ذات صلة في القرن الماضي ، في وقت البطاقات المثقبة ومحركات الأشرطة ، وتم تقديمها لأول مرة في العالم في مقال بقلم W.W. Royce ( دبليو دبليو رويس) ، نشرت في عام 1970.

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

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

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

2. ماذا لو لم يكن الشلال؟

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

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

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

واحدة من أفضل التقنيات المعروفة باستخدام نموذج التطوير التكراري هي Rational Unified Process (RUP). تم تطويره وتنفيذه في النصف الثاني من التسعينيات في Rational Software.

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

مع مزيد من التحليل والمقارنات ، تجدر الإشارة إلى أن بعض الميزات الرئيسية في RUP موروثة جزئيًا أيضًا من تقنية Waterfall.

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

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

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

3. الإطاحة بالأسس

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

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

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

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

ثالثا تحليل لظاهرة منهجيات مرنة

يجب تحليل كل كيان من حيث المنطق قبل أن يتمسك به في فمك.
وودي آلن.

1. تعاريف المنهجيات المرنة

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

أول ما تم العثور عليه في محرك البحث عن طريق مصطلح Agile:

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

يمكن تمييز النقاط المهمة التالية من هذا التعريف:

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

من حيث المبدأ ، لم نتمكن من العثور على الكثير من هذا الوصف ، لذلك دعونا ننتقل إلى التوضيحات:

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

لكننا بالفعل نظرنا في نفس النهج في RUP القديم الجيد. أي أنه لا يوجد شيء جديد هنا بشكل أساسي.

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

لا تتضمن Agile الممارسات ، ولكنها تحدد القيم والمبادئ التي توجه الفرق. Agile هي مجموعة من عمليات التطوير ، وليس النهج الوحيد لتطوير البرمجيات ، ويتم تعريفها بواسطة Agile Manifesto.

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

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

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

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

2. دعنا نحلل الأفكار الرئيسية لـ Agile Manifesto

الأفكار الرئيسية:

1. الأشخاص والتفاعل أهم من العمليات والأدوات ؛
2. منتج العمل أكثر أهمية من الوثائق الشاملة ؛
3. ;
4. .

. . :

1 . , , , . , , . , « – », , .

, , , ( ) . , , .

2 . – , , . - , ? , , , ? , , ? .

. , .

, , , , “” , . . , . . , , , , , .

3 . , . ? , , , , , , ( , ..). : , .. ?

? - ? , , - . – . , , . , . , .

— , , . – .

4. , , , . , , , . , , . , , . , , , .

3. Agile Manifesto

, , Agile Manifesto:

• ;
• ( );
• ( );
• , ;
• , , ;
• — ( );
• — ;
• , ;
• ;
• — ;
• , ;
• . .

.

. , . , . – , , , “”, , , . ?

. , , () , . , , . .

, « , » , Agile, . “” , ( ).

, , — — « ( )». , , , -, .

IV

.
, .
, , , .
.

, ?
Agile, () .

1. , Agile

. , , , .. , , , , , .

, , . , . , .

: , . “ ”, , , . “ ”, . , , “”, . 3-6 , , .

, , – ( ), . , , , , -, , -, , .

2. – Agile

, , . , , . , . – , – .

, . .

, .

3. Agile

يمكن أن يكون استخدام Agile في المشروعات متوسطة الحجم فعالًا جدًا.

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

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

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

4. كيفية الاستخدام الفعال Agile في مشاريع التكامل الكبيرة

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

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

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

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

Agile Unified Process (AUP) هي نسخة مبسطة من العملية الموحدة (UP) التي طورها Scott Ambler. تجمع منهجية تطوير البرمجيات هذه بين عناصر المنهجيات المرنة وعملية موحدة. على وجه الخصوص ، ينطوي AUP على التطوير من خلال الاختبار (TDD) ، واستخدام النمذجة المرنة (نمذجة Agile الإنجليزية) وإعادة بناء قواعد البيانات ، وإدارة التغيير المرنة.

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

5. كيف لا تستخدم رشيق

قسم بنفس القدر من الأهمية ، ربما من أجله تم التفكير في التحليل بأكمله.

1. القائد في التصنيف المعادي هو الموقف عندما يحاولون استخدام Agile ، أو بالأحرى بعض مبادئه ، لا لتحقيق أي أهداف محددة تسمح لهم بضمانها ، ولكن ببساطة #CRAFTLY. لأن هذا هو الاتجاه ، فهو على شفاه الجميع. على سبيل المثال ، شارك شخص ما تعليقات إيجابية في حفل تكنولوجيا المعلومات ، وهو سريع الزوال وحتى متعجرف ، ولكن كان هناك شائعات ، ظهر حاشية. والآن أطلقوا بالفعل على أنفسهم أتباع Agile ، وهم يشعرون بالتواصل مع الباقين - الذين ينتمون إلى نادٍ معين من النخبة. كل هذا يساهم في بساطة واضحة للمنهجية والخطوط العريضة لحدودها. عمليات التنفيذ على هذا المبدأ تحدث بدون تفكير وبشكل رسمي. يقوم الأشخاص رسميًا وغير المبدئي بتنفيذ المبادئ المصممة لتقليل الشكليات.
   
   على سبيل المثال ، واحدة من أحدث الحالات. في إحدى الشركات ، التي تجري عمليات استعادية ، تم حظرها بواسطة Timlids. هنا مثل هذه الشريحة. بشكل غير متوقع الفكر الأول: حسنًا ، ربما يكونون على حق حتى لا يكون هناك ضغط من السلطات على الفريق عند مناقشة المشاكل ، إلخ. لكن Timlids تشعر بالإهانة ، فهي في حيرة وتريد معرفة ذلك. حاولت إقناعي أنهم يقولون إنه قد يكون أفضل ، والشيء الرئيسي هو أن تحصل على قائمة أمنيات ، مع قائمة بما يجب تغييره ، وما يحتاج إلى تحسين ، إلخ. وهنا تم الكشف عن سر رهيب. ولا تظهر أي نتائج أو رغبات لتحسين العمليات نتيجة لهذه التجمعات. السادة IT_shniki ، ولماذا بعد ذلك بأثر رجعي؟ فقط مدح بعضهم البعض وتعزيز روح الفريق؟ قال A ، و B. ، بعد كل شيء ، الغرض الرئيسي من هذه العملية المنهجية هو: "يجب على الفريق أن يحلل بشكل منهجي السبل الممكنة لتحسين الكفاءة وتعديل أسلوب عملهم وفقًا لذلك".
2. الموقف الثاني في التصنيف هو عندما تقرر الفرق التوفير في إعداد المتطلبات في المشروعات التي تحتوي على خوارزميات سلوكية أو منطقية معقدة. وهذا هو ، عندما تكون قصة المستخدم مجرد جزء صغير من جبل الجليد للمشكلة ، وجزءها الرئيسي غير مرئي ويتطلب تحليلاً مفصلاً ودقيقًا وتصميمًا للتنفيذ. ماذا يحدث مع هذا؟
   
   قبل بدء العمل ، لا يفهم العميل ولا المطوّرون تقريبًا حجم العمل الذي يحتاجون إلى القيام به. ووفقًا لذلك: إما أن يدفع العميل ، يدفع ويدفع ، في كل مرة سيشرح له أن كل شيء أصبح أكثر صعوبة وأصبح العمل الآن غير مرئي ونهاية. وبعد كل شيء ، سيكون من المؤسف الإقلاع عن التدخين وسيبدأ تدريجياً في الفهم الصارم على أن هذا المنتج "الذهبي" لن يؤتي ثماره أبدًا. إما أن المطورين ، بعد أن وافقوا على إكمال العمل لفترة معينة من الوقت / الوقت ، سينتهون ويعيدون إنتاج المنتج (مجانًا) على نفقتهم الخاصة حتى نفاد العميل من الخيال ، أو يشعر بالشفقة على ضحايا نهج مرن.
3. يتم اتخاذ المركز الثالث المشرف من خلال الموقف عندما يقرر الفريق في مشروع كبير متعدد الوظائف (وفجأة أيضًا تكامل واحد) أن ينقذ عملية وضع بنية الحلول ويبدأ في تنفيذ قصص المستخدمين الفردية في تكرار قصير. مع درجة عالية من الاحتمال ، سيحدث أنه بعد 3-5 مرات ، عندما تحاول إنشاء وظيفة جديدة ، يتبين أنك تحتاج إلى إعادة العنصر السابق بأكمله ، حيث إن المبادئ الأساسية التي كان يجب أن تستند إليها هذه الوظيفة لم يتم أخذها في الاعتبار. والأسوأ من ذلك ، أنه بعد التكرار العاشر ، تبين أن التقنيات المحددة لا تسمح بتلبية جميع احتياجات العميل ومن الضروري البدء من جديد. ربما عن طريق تغيير الأمر.
4. لم يندرج الموقف الذي بدأت فيه شركة ناشئة حادة ومرنة في اختراق المساحات المفتوحة لقطاع السوق البطيء في المراكز الثلاثة الأولى. بداية ، إنها أيضًا شركة ناشئة ، وهي لا تحتوي على أي أسس أو سندات أو مرفقات ، وفي الوقت نفسه الاستقرار والاستقرار. وببساطة ، لا توجد وثائق تقريبًا ، والفريق ليس متناغمًا وغالبًا ما يتغير. يعمل السوق على تمزيق الفريق حرفيًا ، مطالبًا بمزيد من الحلول الجديدة في هذا المجال ، وكل المشاريع اللاحقة تتفكك ببساطة أمام أعيننا. في معظم الأحيان ، يتم تفسير ذلك من خلال حقيقة أن الفريق ليس لديه فهم لعمليات إنتاج البرمجيات الصناعية ، وتنظيم التسليم ودعم المنتج.

لتلخيص

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

آمل أن يساعد التحليل الفرق التي تستخدم منهجيات أخرى للاستفادة من نهج Agile إذا لزم الأمر.