اقتباسهل تعتقد أنك تدير مشاريعك بمنهجية أجايل حقًا؟ ماذا عن المراسم المعيبة وضعف التواصل وبطء سير العمليات؟ هذه كلها مؤشرات خطر تدل على أنك تتبع منهجية أجايل بطريقة مزيفة.
- برادلي مومبرجر
لوحظ على الكثير من الفرق التي تدّعي أنها تعمل بمنهجية أجايل عيوبٌ جسيمة، مثل الإجراءات المقيَّدة ودورات التطوير التي لا تنتهي وانسداد مسار ضمان الجودة. وتنشأ معاناة هذه الفرق من الهوّة الكبيرة بين ما يعتقدون أنها منهجية أجايل من جهة، وما هي منهجية أجايل الحقيقية من جهةٍ أخرى. لنتحدث بالتفصيل عن الأخطاء الشائعة التي تقع بها بعض الفرق التي تطبق منهجية أجايل معيبة، مع التطرق إلى الحلول الممكنة لتحسين تقديم البرمجيات ورفع معنويات المطورين.
ما هو المفهوم الصحيح لمنهجية أجايل؟
أجايل هي منهجية تسعى للمساعدة على تقديم البرمجيات بالشكل الذي ترغب به الأطراف المعنية. نشأت هذه المنهجية على أنقاض العقبات والمصاعب التي كانت تواجه نماذج التطوير السابقة، والتي كانت تنص على أن البرنامج يجب أن يكون أولًا واضح المعالم ثم تجري هندسته، بعدها يقدَّم بشكله النهائي المكتمل.
كانت النماذج السابقة لأجايل تحمل مخاطر كبيرة، فعند تقديم البرنامج بشكله المكتمل، قد تكون احتياجات العميل قد تغيرت بحلول نهاية المشروع، وربما يتبين أنها لم تكن مفهومةً جيدًا عندما تم افتراضها في البداية.
لكن منهجية أجايل ليست كذلك، فمن خلال إبقاء قناة التواصل مفتوحة، يمكن تغيير المتطلبات قبل هدر الوقت والجهد في تنفيذ منتج خاطئ، ويمكن تقييم التعديلات الجديدة للتحقق من ملاءمتها.
يجب أن تنبع جميع عمليات وهيكليات أجايل من القيم والمبادئ التي تنص عليها اتفاقية أجايل، كما يجب الاستفسار عن سبب كل قرار تقني وكل ممارسة ودور ضمن العمل، ليكون التبرير مرتبطًا بواحد أو أكثر من هذه القيم والمبادئ.
مع ذلك يمكن القول أن فرق أجايل تنفذ جميع عمليات وهيكليات أجايل دون أن تحقق مكاسب بسهولة، والقاسم المشترك بين الفرق التي تعاني من صعوبات هي أنها تنتهج منهجية أجايل من خلال ممارسات مقيَّدة وصارمة، بدلًا من أن تستفيد من المرونة التي هي السمة العامة لهذه المنهجية كما يشير اسمها.
تزييف أجايل: مخاطر التقليد السطحي
ربما مرّت عليك بعض المتاجر التي يدّعي أصحابها أن لديهم منتجات مطابقة للعلامات التجارية الأصلية، يتركز هؤلاء البائعون في أسواق معينة، وتفتقر متاجرهم لعلامة تجارية ذات سمعة، إلا أن ميزتهم الوحيدة هي انخفاض أسعار منتجاتهم.
على سبيل المثال، من الممكن أن تشتري سماعات لاسلكية لها نفس شكل سماعات آبل ونفس حجمها ولونها، لكن عندما تستلمها تلاحظ أن التشابه ينتهي عند الناحية الشكلية والجمالية، وذلك عندما تواجه صعوبةً بربطها بأجهزتك، كما تكتشف لاحقًا أن الصوت من خلالها رديء. صحيح أن السماعات مجهولة الاسم قلدت بشكلها الخارجي سماعات آبل من خلال استنساخ مواصفاتها الخارجية لكي تزداد فرص بيعها، إلا أن مواصفاتها لم تكن فعالة بما يكفي لتعطي منتجًا مفيدًا.
هناك الكثير من فرق العمل التي تقع في فخ ملاحظة شيء يفعله الآخرون ويقودهم إلى النجاح ثم محاولة تقليده، لكن بطريقة خاطئة بسبب الفهم غير المكتمل؛ لذا يمكن القول أن الاستيعاب العميق لنطاق المشكلة هو المفتاح لإيجاد حلول ملائمة. وبغياب هذا الاستيعاب، يحصل الفريق على حلول غير متوافقة بدلًا من الحلول المدروسة.
عندما تسبب حلول أجايل المقلَّدة مشكلات أو نتائج عكسية، من الشائع الاعتقاد بأن "الحل يجب أن يكون صحيحًا لأننا نسخناه من أشخاص ناجحين، لذا فإن المشكلة ببساطة تكمن في عدم قدرة الأشخاص على التكيف معه مما يجعله سببًا للتباطؤ أو الضرر". وللأسف فإن هذه العقلية منتشرة جدًا رغم فظاعتها.
خصائص النسخة الزائفة من منهجية أجايل
يحدث تزييف أجايل عندما يطبَّق إطار عمل أجايل شكلي على تطوير البرمجيات، أي يكون هذا الإطار مشابهًا شكليًا فقط لقيم ومبادئ أجايل الحقيقية. بمعنى آخر، فإن النسخة الزائفة من منهجية أجايل هي نسخة سطحية قد تبدو مشابهة لممارسات أجايل شكليًا، لكن دون أن تراعي حقيقةً تلبية هذه المبادئ.
في منهجية أجايل الزائفة، يقيم مدرب إطار عمل سكرام Scrum دورات تطوير تستغرق وقتًا معينًا وتتضمن اجتماعات خلال أيام وأوقات محددة، ويكون مالك المنتج أو ما يقابله من مسميات الإدارة هو المرجع الوحيد لكل النقاشات ضمن الفريق أو بين الفريق والأطراف المعنية، وبذلك فإن كل ما تقدمه هذه الاجتماعات من مزايا تعزيز التواصل واكتشاف الحلول يكون موجَّهًا إلى مديري الفريق؛ مما يحدّ من قدرات المطورين بدلًا من تعزيز استنباطهم لنتائج أفضل.
مؤشرات الخطورة التي تدل على تزييف أجايل
فيما يلي مجموعة متنوعة من الحالات القصيرة عن قصص مبرمجين مستوحاة من تجارب الحياة الواقعية، والتي قد تذكِّر المطورين الخبراء بتجارب سابقة مروا بها؛ أما المستجدين من المطورين فقد يتعين عليهم دراسة هذه القصص بعناية ليتعرفوا من خلالها على مؤشرات الخطورة.
المراسم
تهدف مراسم أجايل إلى تخفيف العقبات وإبقاء المشاريع على المسار الصحيح، أما في منهجية أجايل الزائفة فتتحول المراسم بحدّ ذاتها إلى عقبات، حيث تسلط الحالات القصيرة التالية الضوء على مؤشرات الخطورة التي تنبه إلى تزييف منهجية أجايل في المراسم.
- الاجتماعات اليومية السريعة Stand-up:
-
حالة أجايل الزائفة الأولى: يعتمد عقد الاجتماع اليومي لمناقشة الوضع على تفرُّغ مسؤول سكرام (وقد لا يُعقَد بالأساس)، ويختلف توقيت الاجتماع حسب الظروف اليومية؛ أما موعده المسجَّل فهو للاستئناس فقط، ويُتوقَّع من المطورين أن يكونوا متاحين في أي موعد يتغير إليه توقيت الاجتماع. وفي حال لم يكن أحد المطورين متفرغًا، فيجب أن يرسل تقرير تقدمه اليومي إلى مسؤول سكرام عبر رسالة خاصة. في بعض الأحيان يُطلب توثيق رقم كل مشكلة يعمل عليها المطور أو عالجها فعليًا، رغم أنه لا أحد يهتم بنظام تتبع المشكلات أثناء اجتماع التقدم اليومي.
-
الدرس المستفاد: الاجتماع اليومي ليس مجرد تقرير يومي يقدَّم إلى الإدارة، بل إن هذه الاجتماعات أُعِدت من أجل المطورين، لضمان عدم تعطل عمل أي مطور بسبب مشكلات يمكن تلافيها، وللتحقق من أن تسليم العمل يسير على ما يرام. والنقطة الأهم أن الاجتماعات اليومية السريعة لا يُشترط أن يديرها شخص معين، وفي حال كان هناك حاجة لتغيير موعدها، فيجب أن يكون ذلك بالتوافق.
-
-
حالة أجايل الزائفة الثانية: يجب عقد اجتماع يومي ثانٍ عبر اتصال هاتفي مع فريق المطورين في الهند، لأن الفريق يحتل مكانة أعلى من الفريق المحلي في التسلسل الهرمي للشركة، رغم أن الاجتماع اليومي الأول الذي لا يشارك فيه الفريق الخارجي هو الاجتماع الوحيد الذي تصدر عنه نتائج مفيدة.
-
الدرس المستفاد: التوتر الناجم عن تنظيم الفريق من قِبل طرف خارجي يسبب خلافات. في الحالة السابقة، لم يكن هناك أي علاقة تربط الفريقين ببعضهما، وكان التواصل بينهما يجري نتيجة الضغوطات التنظيمية الخارجية فقط، وهذا ما قد يعطي انطباعًا للمهندسين بأنهم غير مؤهلين لتنظيم أنفسهم بأنفسهم، مما يقلل من سوية أدائهم.
-
- الاجتماعات الاسترجاعية Retrospectives:
-
حالة أجايل الزائفة: يعقَد اجتماع استرجاعي بين الحين والآخر، ويكره الجميع حضوره. يتعين على كل مطور أن يقدم تعليقًا واحدًا على الأقل عن كل حالة سارت على ما يرام أو تحتاج إلى تحسينات. تُكتب هذه البنود في جدول بيانات جوجل، لكن لا يُحال أي منها إلى نظام تتبع المشكلات ليصبح قابلًا للتنفيذ، ناهيك عن وضعها قيد العمل في دورتي التطوير التاليتين. يُنسخ جدول بيانات الاجتماع الاسترجاعي من تقرير الاجتماع السابق مع وجود عنوانين ثانويين وهما "السابق" و"الجديد" في كل تقرير؛ والتي تشير إلى بنود الاجتماع السابق والحالي، إذ تنتقل المشكلات التي كانت "جديدة" في الاجتماع السابق لتصبح مشكلات "سابقة"، رغم أنها لم تخضع للمعالجة عندما كانت جديدة. والنقاش الوحيد الذي يدور حول البنود هو التفسير الشفهي الذي يتعين على كاتب البند تقديمه.
- الدرس المستفاد: يجب أن ينتج عن الاجتماع الاسترجاعي بنود قابلة للتنفيذ، وفي حال الاتفاق على إجراء تغيير ما، فيجب إعداد خطة لتطبيق هذا التغيير، ويجب إدراج هذه الخطة بعد ذلك ضمن المشكلات التي يجب تتبعها. لا يمتلك أحد في هذا السيناريو صلاحية تغيير طريقة الاجتماع الاسترجاعي لتصبح أكثر ملاءمة، في حين أن بيئة عمل أجايل الحقيقية تتيح إمكانية وضع أي أمر على طاولة عمل الاجتماع الاسترجاعي، ولا يستثنى من ذلك كيفية إجراء الاجتماع الاسترجاعي بحدّ ذاته.
- العروض التوضيحية Demos:
-
حالة أجايل الزائفة: نادرًا ما تجرى عروض توضيحية، وهو أمر مفسَّر نظرًا لأن الكود البرمجي نادرًا ما يتجاوز مرحلة المراجعة. وعند إجراء عروض توضيحية، فإنها تُقدَّم عادةً من الجهاز المحلي للمطوِّر أو من خادم التطوير. ليس هناك تأكيد على ما إذا كان العميل بحاجة إلى الميزة التي يعمل المطور على توضيحها، وحتى العميل لا يكون متأكدًا من ذلك، ربما سيتمكن من الإجابة عن ذلك بعد ثلاثة أيام من هذه المرحلة.
- الدرس المستفاد: لا شك بأن الفريق غير القادر على إجراء عروض توضيحية يعاني من مشكلة أساسية تتمثل بنقص تسليم العمل، أي أن البنود لا تصل إلى مرحلة الإنتاج. يجب أن يشرح العرض التوضيحي "ميزات يمكن استخدامها في الوقت الحالي"، ولا بأس بأن يقرر العميل لاحقًا أنه لا يريد هذه الميزة، إذ يمكن إزالتها مرةً أخرى، لكن وضعها ضمن مسار الإنتاج يتضمن بالضرورة إعداد عروض توضيحية لجمع المعلومات من خلال اختبار المستخدم والملاحظات.
- اجتماعات تخطيط دورة التطوير Sprint Planning:
- حالة أجايل الزائفة: تعقَد اجتماعات تخطيط دورة التطوير في اليوم الذي يسبق بداية دورة التطوير، وتمتد إلى اليوم الذي من المفترض أن تبدأ فيه دورة التطوير. وبالنسبة لموعد الاجتماع فهو متفق عليه سابقًا، والهدف الوحيد من الاجتماع هو أن يحدد المطورون حجم العمل اللازم لحل المشكلات بمقياس نقاط القصة story points.
الأمر المثير للاهتمام هو أن المشكلات المحددة لا تضاف إلى التزامات العمل، بل تُترَك لتجد طريقها لاحقًا إلى طاولة عمل دورة التطوير دون بذل أي جهد لتحقيق ذلك.
من ناحية أخرى، عندما يُطلب من الجميع تحديد رقم لتقدير نقاط القصة من وجهة نظرهم (لتقدير حجم المهام)، فإن الشخص الذي وضع الرقم الأعلى لنقاط القصة هو الوحيد الذي يتعين عليه تبرير هذا الرقم، وتكمُن المشكلة هنا عندما يكون قد وضع رقمًا مرتفعًا ليس لشيء إلا لقلة خبرته بالموضوع؛ عندها سيُرغَم المطور قليل الخبرة على تقليل حجم العمل المقدر لحل المشكلات وسيُكلَّف بإنجاز هذا العمل عقوبة ً له. وكل ما سيحصل عليه هذا المطور هو عنوان المشكلة منسوخًا من ملف الإكسل الذي كتبه مدير المشروع، ولن يحصل على أي توصيف أو توضيح آخر.
-
الدرس المستفاد: يجب أن ينعكس التخطيط لدورة التطوير مباشرةً على دورة التطوير، وربما من الأفضل تنفيذه في مرحلة متأخرة من دورة التطوير عندما تكون المشكلات قد تجاوزت مرحلة البرمجة ونجحت باختبار ضمان الجودة. بالنسبة للقصة أعلاه. يجب أن يتضمن الاجتماع الاسترجاعي التالي مناقشة المشكلات التالية:
- الحاجة لتغيير جدول عمل تخطيط دورة التطوير، وذلك ربما من خلال تخصيص مزيد من الوقت في اليوم الأخير من دورة التطوير أو توزيع الوقت المطلوب على مدار دورة التطوير.
- العيوب التي تعالَج بطريقة غير صحيحة باعتبار أنها غير مؤثرة على نطاق العمل.
- تقدير الوقت أو الجهد بطريقة غير دقيقة لتشجيع الالتزام بعبء أكبر من العمل.
- إدراج قضايا غير مكتملة على أنها جاهزة للتنفيذ.
كل من النقاط السابقة هي مشكلة تحتاج إلى مناقشتها، لكن إذا لم يبذل الفريق جهده لإصلاح هذه المشكلات، فلن يقتصر التأثير عليها، بل إن آثارها ستمتد لتترتب عليها مشاكل أخرى:
- ستبدأ دورات التطوير بوقت متأخر أكثر فأكثر، أو تصبح غير محددة المعالم، أو كليهما.
- ستكون هناك حاجة دائمة لاستمرار دورات التطوير لأوقات إضافية، أو ستتراكم العيوب غير المعالجة، أو كليهما.
- ستتناقص السرعة التي تقاس بنقاط القصة.
- لن تلبى التزامات دورة التطوير.
- سيتطلب الأمر معالجة المشكلات مرة ثانية، ولن يلبي العمل الغايات المطلوبة من القصة، أو كليهما.
الموظفون
هناك حالتين زائفتين شائعتين هنا.
-
حالة أجايل الزائفة الأولى هي أن يكون هناك مالك المنتج، ومالك المنتج التقني، ومدير المنتج، ومدير المشروع، ومسؤول سكرام، ومدرب أجايل، والمدير التقني، ومدير الهندسة، والمهندس المعماري؛ فضلًا عن المطورين العاديين. يستغرق اجتماع الوضع اليومي 40 دقيقة، ويجب أن يقف الجميع على شكل دائرة وأن يتحدثوا من خلال هاتف مكبر صوت موصول بخدمة Webex، ليتمكن المدير المسؤول عن المشروع عن بُعد من سماع الحالة اليومية، كما يتمكن بذلك أي شخص عالق في الزحام متأخر عن العمل من حضور الاجتماع.
- الدرس المستفاد: العدد المثالي للفريق هو 5 إلى 7 أعضاء، ويجب ألا يكون غالبيتهم من المديرين أو أصحاب السلطة، مع التأكيد مرةً أخرى على أن الاجتماعات اليومية لا تهدف إلى تقديم تقرير عن الوضع للمديرين، ولا تتطلب عادةً أن يتكلم فيها غير المطورين.
وللتأكيد، إذا تجاوز الاجتماع اليومي 15 دقيقة، فإنه يفقد قيمته للجميع، لأن الغاية منه هي تركيز الأفكار لا تشتيتها. وإذا كان الاجتماع يُعقَد في وقت لا يزال فيه الأشخاص في طريقهم إلى المكتب، فلا بد من مراجعة توقيته.
اقتباسالقصة المذكورة أعلاه تعود إلى ما قبل انتشار مكالمات الفيديو على نطاق واسع، أما بالنسبة للمكالمات الصوتية بدون فيديو فهي تحدّ كثيرًا من التواصل المطلوب بين المطورين وتقلل من قدرتهم على تقديم الدعم عندما يطرح أحدهم مشكلة تعترضه ويطلب المساعدة.
-
حالة أجايل الزائفة الثانية: يكون المطورون موزعين بخبرتهم بالتساوي بين موظفين بدوام كامل وموظفين بعقود، وفجأةً دون سابق إنذار تُنهى عقود جميع أصحاب العقود، ورغم ذلك يُتوقع أن تبقى سرعة الفريق على حالها.
- الدرس المستفاد: لا يقتصر الأمر على مشاريع أجايل، لكن يجب تجنب تغيير الموظفين في مشاريع البرمجيات عمومًا، فالثقة المطلوبة داخل الفريق من أجل تنفيذ مشروع أجايل فعال تتراكم مع الزمن، وفي حال تطلَّبَ الأمر إعادة بنائها مع موظفين جدد فلا بد أن يؤدي ذلك إلى نتائج عكسية. وفقًا لقانون بروكس Brooks's Law، فإن التأخير الناتج عن تغيير الموظفين يصبح مضاعفًا عندما يكون مشروع البرمجيات تحت ضغط زمني.
المواعيد النهائية
هناك حالتين زائفتين شائعتين فيما يخص المواعيد النهائية:
-
حالة أجايل الزائفة الأولى هنا هي عندما يتم الضغط على زر الانطلاق الفعلي في دورة التطوير الحالية ضمن نظام تتبع المشكلات عند حلول اليوم الثالث من برنامج دورة التطوير، حين يُكمل مصدر هندسي واحد على الأقل مرحلة التطوير لكي يبدأ بمهمة جديدة بعد أن يتأكد من أنه لم يتبقَّ أي شيء من دورة التطوير السابقة ضمن قائمة الأعمال التي يجب القيام بها أو الجاهزة للتطوير، في الوقت الذي يكون فيه المطورون الآخرون لا يزالون يعملون على مهام دورة التطوير السابقة. وقد يضطر المطور الذي يبدأ بالعمل على مهام دورة التطوير الجديدة إلى التراجع في أي وقت إذا لم يجتَز الكود الذي تعهدَ بتسليمه مرحلةَ المراجعة بنجاح.
- الدرس المستفاد: يجب أن يُنهي جميع المطورين مهام التطوير في نهاية دورة التطوير، وكل أعمال تسلَّم متأخرة هي مؤشر على وجود مهام تطوير إضافية، والتي لا يمكن تخصيص وقت لها إلا من خلال تقليص نطاق دورة التطوير القادمة (تقليصًا مضاعفًا بالنسبة لدورة التطوير القادمة من أجل معالجة المشكلات الإضافية لدورة التطوير الحالية، وتقليصًا مفردًا بالنسبة للدورة اللاحقة حفاظًا على التوازن).
إذا تكرر حدوث ذلك فهو مؤشر على وجود مشكلة بالالتزام بدورة التطوير أو توتر بين المطورين، وعندها يصبح تحديد نطاق دورة التطوير هدفًا أساسيًا يجب مناقشته في الاجتماع الاسترجاعي القادم.
-
حالة أجايل الزائفة الثانية: دُمِجت الأعمال التي يجب تسليمها في دورة التطوير السابقة مع الأعمال التي يجب تسليمها في دورة التطوير الحالية، لأن فريق ضمان الجودة لم يبدأ بها بعد. ولم يُنشَر أي تحديث للمنتج منذ ثلاثة شهور.
- الدرس المستفاد: قد يكون تأخر فريق ضمان الجودة مؤشرًا على ثقل برنامج عمل دورات التطوير أو انخفاض جودة البرمجيات أو تراكم أعمال خط ضمان الجودة، أو توليفة من هذه الأسباب.
يشير وجود عقبات أمام الإنتاج إلى وجود مشكلة في آلية التسليم المستمر إلى الإنتاج، والذي قد ينجم عن عدم اجتياز اختبار قبول المستخدم أو نقص الكوادر التي تعمل عليه، أو ربما يحدث ذلك رغم اجتياز اختبار قبول المستخدم بسبب اعتقاد مالك المنتج أن النشر ليس جاهزًا!
يُعَد السعي نحو الكمال مشكلةً واقعيةً وشائعةً ضمن فرق أجايل، والعلاج الوحيد لها هو الرضا والقبول بتسليم عمل دون مستوى الكمالية إلى المستخدمين ومن ثم جمع ملاحظاتهم وإجراء تحسينات عليه.
التواصل
هناك أيضًا حالتي أجايل زائفتين بخصوص التواصل:
-
حالة أجايل الزائفة الأولى: تعمل مجموعة صغيرة من مالكي المنتج ومديري سكرام على تحويل جميع عمليات التواصل من الأطراف المعنية إلى المطورين، وبذلك تصبح الأطراف المعنية مجهولة تقريبًا بالنسبة للفريق، مع عدم وجود طريقة للتواصل معهم، مما يؤدي إلى تعذر إجراء اختبارات المستخدمين (الذين يُعَدّون من ضمن الأطراف المعنية).
- الدرس المستفاد: يتعارض أسلوب التواصل هذا مع المبدأ الرابع من مبادئ أجايل الذي ينص على أن "أصحاب المشروع والمطورين يجب أن يعملوا على المشروع جنبًا إلى جنب يوميًا".
عندما يكون مسار جميع عمليات التواصل موجهًا نحو نقطة ضيقة، فقد يتعذر التعاون مع العملاء (القيمة الثالثة من قيم أجايل). وبغياب التعاون يفوِّت الفريق فرص الاستجابة للتغيرات في احتياجات الأطراف المعنية أو تفاضيلاتهم.
-
حالة أجايل الزائفة الثانية: فرق المحتوى المتعددة ضمن المؤسسة هي المسؤولة عن تعبئة المنصة التي يعمل المهندسون على إعدادها، وعندما لا يُملَأ المحتوى تنعدم فائدة التطبيق، ويقع اللوم على المهندسين؛ وعندما يترأس الفريق نائب جديد ويجمع الفريق ليخبرهم بتكليفه، يهمل تقصير النائب السابق ويطرد مدير الهندسة الذي يحظى بسمعة طيبة، ويبقى المحتوى مفقودًا.
- الدرس المستفاد: الحاجة إلى التعاون لا تقتصر على العملاء، وفي هذا المثال كان من الضروري أن يجري التواصل بين المطورين وفرق المحتوى من أجل الحد من ترددهم في نشر محتواهم ضمن النظام الجديد.
بسبب عدم حدوث هذا التواصل، حدث تأجيل في توفير محتوى بالتنسيق الذي يتطلبه النظام الجديد على نطاق واسع. وقد أدت القيود الصارمة التي فُرضت على التواصل مع فرق المحتوى إلى تعذر تواصل المهندسين معهم، مما انعكس سلبًا على المشروع برمّته.
العمليات التقنية
حالة أجايل الزائفة هنا هي عندما يجري تغيير قاعدة البيانات المحلية للمطورين إلى آلية مختلفة عن بيئة التحضير والإنتاج. ويكون هناك مشروعان واحد منهما فقط لديه محرك لترحيل قواعد بيانات، أما المشروع الآخر فيتعين عليه توجيه جميع طلبات التغيير عبر المستشار التقني لإجراء تحديثات يدوية، لكن المستشار التقني لا يتمتع بأي خبرة بإدارة قواعد البيانات.
- الدرس المستفاد: التكامل المستمر والنشر المستمر CI/CD ونموذج DevOps هما عنصران أساسيان من مسار عمل أجايل، لكن يمكن أن تعرقلهما عمليات بشرية تسبب التباطؤ. بالنسبة لحالة قواعد البيانات، من الأفضل وضع شروط لترحيل البيانات قبل البدء بأي مشروع، ومع ذلك فيمكن تطبيق شروط ترحيل البيانات على أي مشروع يأتي فيما بعد، يجب أيضًا الاهتمام بشكل خاص باختيار سياسات السحابة، نظرًا لأن المطورين يحتاجون إلى تراخيص الاستخدام الفردي أو تكنولوجيا مكافئة من أجل التطوير المحلي.
الخلاصة
تتمثل أولويات منهجية أجايل الحقيقية بتقديم برمجيات فعالة قائمة على التواصل المستمر والقدرة على التكيف، مع الالتزام بقيم ومبادئ اتفاقية أجايل. مع ذلك فإن الكثير من الفرق تقع في فخ تزييف منهجية أجايل، وذلك من خلال تطبيق نسخ ظاهرية من ممارسات أجايل دون الالتفات إلى مبادئه الأساسية.
للاستفادة من مزايا أجايل كما يجب، لا بد وأن يبدي الفريق استيعابًا عميقًا لنطاق المشكلة، وأن يوفر المناخ الملائم للمطورين لتنظيم عملهم؛ مع الحرص على التواصل الفعال، وإعطاء الأولوية لتسليم العمل والحصول على ملاحظات المستخدمين، وضمان أن تدعم العمليات التقنية استمرارية التكامل والنشر. لا بد من الالتزام بهذه المبادئ لكي تتمكن الفرق من تحقيق النجاح عبر منهجية أجايل.
ترجمة -وبتصرّف- للمقال You're Doing Agile Wrong لصاحبه Bradley Momberger.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.