تستخدم آلاف فرق العمل حول العالم ممارسات ومبادئ أجايل لتطوير البرمجيات، ولا يختلف اثنان حول حقيقة أن منهجية أجايل أصبحت الطريقة الأشيع لتحويل الأفكار إلى أكواد برمجية. لكن رغم شعبية أجايل وتأثيرها الكبير، إلا أنها تتضمن بعض الجوانب التي قد تؤثر على نجاح المنتجات والخدمات المطوَّرة باستخدام أجايل.
أُنشِئت أجايل على يد مطورين ومن أجل المطورين، ولم يكن أحدٌ من مبتكريها مصممًا، لذلك لم يحصل التصميم على نصيبه من الاهتمام، وكأن التصميم ضيفٌ منبوذ لم يتلقَّ تذكرةً ذهبيةً لدخول معمل أجايل السحري.
مع ذلك، احتاج المصممون دائمًا إلى تكييف عملهم في التصميم مع المنهجية المتبعة للعمل على المنتج. ونظرًا لعدم دعم منهجية أجايل عند إنشائها لجانب التصميم دعمًا كافيًا، فقد جعل هذا الكثير من فرق العمل تتبع ممارسات سلبية بهذا الخصوص، مما أدى في عدة حالات إلى الحصول على تصميم رديء وتجربة مستخدم سيئة، وبالتالي منتجات وخدمات لا ترقى إلى النجاح المطلوب.
سنسلط الضوء في هذا المقال المكوَّن على عشرةٍ من أبرز الممارسات السلبية التي قد تلحق الضرر بالمنتج، مع بيان كيفية تجنب الوقوع في هذه الممارسات:
غياب التصميم المسبق
ينفر أتباع منهجية أجايل من فكرة إنجاز تصميم مسبق، ويكادون يُنزلونها منزلة التحريم، إذ يدعو إعلان أجايل للتطوير إلى اعتبار الآتي وفقًا لإعلان أجايل لتطوير البرمجيات:
- الأفراد وتعاملهم فيما بينهم فوق المنظومات والأدوات
- البرمجيات الصالحة للاستعمال فوق التوثيق الكامل
- تعاون ومشاركة العميل فوق التفاوض حول العقد
- الاستجابة للتغييرات فوق الالتزام بمخطط عمل محدد
يقوم الفكر السائد على الاعتقاد أنه بدلًا من إضاعة الوقت على عمل تصميم مسبق، يمكن للفريق إنشاء نموذج سريع وإطلاقه للحصول على ملاحظات العملاء، ومن ثم تعديله وفقًا لهذه الملاحظات؛ لكن المشكلة تكمُن في أن تغيير المنتج بعد إطلاقه يُعَد عمليةٌ صعبةً ومكلفةً وضارةً إلى حدٍّ كبير، فالمنتج المتغير باستمرار قد يكون مربِكًا للمستخدمين ويؤدي إلى تراكم تكاليف التصميم وارتفاع الهدر بسبب الاستغناء عن التصاميم غير المدروسة.
لا انعدام التصميم المسبق ولا قضاء شهور في التصميم المسبق هو الحل المناسب، بل ينبغي بذل بعض الجهود التصميمية اللازمة فقط. فيمكن مثلًا تخصيص دورة تطوير Sprint مدتها أسبوع من أجل التصميم السريع وإعداد نموذج أولي ومن ثم تقييم الفكرة.
يساعد إجراء القدر اللازم من التصميم على نجاح فرق عمل أجايل.
مصمم وباحث في آن واحد
تميل منهجية أجايل إلى الشخص متعدد القدرات الذي يمكنه إنجاز جميع الأعمال، أما المتخصصين فيُنظر إليهم أحيانًا على أنهم السبب في عرقلة العمل وتأخيره. غالبًا ما يتكون فريق أجايل من ذوي الخبرات العامة ليتسنى لأي شخص من الفريق القيام بأي عمل يحتاج للإنجاز.
لهذا السبب فإن فرق أجايل تفضّل المطور الشامل Full Stack على المتخصص بتطوير الواجهة الأمامية، كما ترجّح المصمم والباحث الشامل على وجود مصمم متخصص مع باحث متخصص.
المشكلة ليست فقط في صعوبة إيجاد شخص بارع في التصميم والبحث على حدٍّ سواء، بل في قدرة هذا الشخص على إنجاز عبء العمل الذي يحتاج لشخصين، لذا فإن الأفضل هو توظيف مصمم متخصص مع باحث متخصص أو مصمم شامل مع مصمم آخر مساعد، مما يدعم المتطلبات المتوازية لكل من التصميم والبحث، كما أن العثور على شخصين يتمتعان بمهارات متكاملة أسهل بكثير من العثور على شخص يجمع بين جميع المهارات.
التخطيط المسبق لدورة تطوير واحدة فقط
يدعو إعلان أجايل إلى ترجيح الاستجابة للتغيرات بدلًا من اتباع خطة، مما يجعل الكثير من فرق أجايل تفسر ذلك بعدم الحاجة لإعداد خطة على الإطلاق، أو في أحسن الأحوال إعداد خطة مسبقة لدورة تطوير واحدة فقط.
لكن في الواقع، تحتاج فرق أجايل إلى إعداد خطة والتفكير بما يتعدى دورة التطوير التالية، فغياب الخطة طويلة المدى يؤدي بالفريق إلى اتخاذ قرارات تناسب الحالة الآنية, لكنها تؤدي لاحقًا إلى الندم، مثل اختيار نمط تنقُّل غير قابل للتوسيع مع نمو المنتج، أو تطوير ميزات معزولة عن بعضها دون وجود رؤية شاملة.
قد يؤدي غياب التخطيط المسبق أيضًا إلى تراكم الكثير من النفقات بسبب نقص التنسيق والانسجام بين دورات التطوير.
ليس المقصود هنا التخطيط لكل شيء مسبقًا، بل يكفي وجود تصور مسبق لمضمون دورات التطوير الثلاثة أو الأربعة القادمة، والتحقق من انسجام العمل مع رؤية المنتج طويلة المدى. يمكن إنجاز ذلك من خلال إعداد قصص المستخدمين، وهو عبارة عن نشاط جماعي يتضمن تقسيم رحلة المستخدم والمهمات إلى أعمال يتولى الفريق تنفيذها.
إعداد قصص المستخدمين طريقةٌ رائعة تمكّن فرق أجايل من إنجاز التخطيط اللازم.
البحث والتصميم وتسليم العمل في الدورة نفسها
نظرًا لأن فريق أجايل لا يميل لإنجاز الكثير من التصميم والبحث المسبق، فإنه يضطر إلى إنجاز البحث والتصميم وتسليم قدر من العمل في دورة التطوير نفسها، وهو ما يشبه الهرع إلى مدّ سكك حديدية للقطار بالتزامن مع مروره.
المشكلة أن اللحاق بهذا القدر من الأعمال غير ممكن في معظم الأحيان، فمحاولة ضغط عمليات التصميم والبحث والتسليم في دورة تطوير بطول أسبوع أو أسبوعين ترتّب عبئًا كبيرًا من العمل على الفريق؛ إذ يتعين على الفريق في هذه الحالات وضع عدد هائل من الفرضيات لأنه لا سبيل لاختبار الأفكار المطروحة، لينتهي بهم الحال باختيار أفكار التصميم الأسهل تنفيذًا بدلًا من الأفضل لكي يتمكنوا من اللحاق قبل نهاية دورة التطوير، وفي النهاية يقدّمون عملًا غير مكتمل لأنهم بحاجة لتقديم نتيجةٍ ما في نهاية دورة التطوير.
لذا بدلًا من محاولة إنجاز البحث والتصميم وتسليم العمل في الدورة نفسها، من الأفضل اتباع مسارَي استكشاف وتسليم منفصلَين لكن متعلقين ببعضهما. تسمح هذه المنهجية ثنائية المسار الموضَّحة في الصورة، باستكشاف الأفكار والفرص الممكنة واختبارها قبل التسليم.
تُعَد المنهجية ثنائية المسار طريقةً رائعةً لإنجاز أعمال البحث والتصميم قبل التسليم.
عدم التكرار بعد الإصدار
تنساق الكثير من فرق أجايل وراء مقولة:
اقتباسسنطلق الميزة ونأخذ ملاحظات المستخدمين ومن ثم نعيدها بناءً على الملاحظات
وهو مبدأ جيد نظريًا؛ لكن نلاحظ عمليًا أن الكثير من هذه الفرق تصبح مصنع ميزات في نهاية المطاف، إذ أنهم يطلقون نسخةً مبدئيةً من الميزة ويَعِدون أنفسهم بتكرارها بعد الحصول على الملاحظات، لكنّهم لا يعودون إلى ذلك أبدًا، بل ينتقلون إلى الميزة الجذابة التالية ومن ثم التي تليها واحدةً تلو الأخرى، إلى أن تصبح النسخة المبدئية من الميزة الأولى جزءًا من الماضي.
لا نقصد هنا أن التكرار شرط لازم ولو لم يكن له مبرر، لكن في الواقع تحتاج 9 من كل 10 ميزات إلى التكرار بعد الإصدار الأولي، لذلك يتعين على فرق أجايل أن تخطط للتكرار، وترك وقت كافٍ بين التكرارات لجمع ملاحظات المستخدمين من أجل تطوير النسخة المكررة على ضوئها.
نقص معايير مراقبة جودة تجربة المستخدم
عندما تفكر فرق أجايل بمدى الحاجة لميزة جديدة، فغالبًا ما تُطرح عبارات مثل:
- هل هناك أخطاء؟
- هل هناك فشل في الاختبارات التي أُجريت على الميزة الحالية؟
وهذا بالرغم من أن غياب الأخطاء وغياب حالات الفشل في الاختبارات لا يعني بالضرورة أن الميزة الحالية عالية الجودة، فقد يكون الكود صالحًا لكن الميزة صعبة الاستخدام أو غير ذات قيمة للمستخدمين أو ذات تأثير سلبي على تجربة المستخدم الشاملة.
ولهذا السبب، من الضروري أن تمتلك فرق أجايل معايير مراقبة جودة يمكن استخدامها في التقييم الذي لا يقتصر على جودة الكود البرمجي فحسب، بل يمتدّ إلى تقييم جودة تجربة المستخدم التي يقدّمها هذا الكود، مثل تقييم سهولة استخدام ميزة جديدة عبر اختبار سهولة الاستخدام، أو إجراء مراجعة لسهولة الاستخدام وإمكانية الوصول قُبيل الإطلاق.
تستفيد فرق أجايل أيضًا من إعداد قائمة بنود تحقُّق متعلقة بتجربة المستخدم، والتي تساعد على وضع المعايير اللازمة لمراقبة جودة تجربة المستخدم.
انتظار ملاحظات المستخدمين
تفترض الكثير من فرق أجايل أن المستخدمين سيُبلغونها مباشرةً بالأخطاء عند اكتشافها، فتعمل هذه الفرق على إنشاء تصميم مبسَّط، ربما بناءً على الافتراضات، ثم انتظار تدفُّق الملاحظات من المستخدمين. لكن المشكلة التي قد تحصل هنا هي أن معظم المستخدمين يكونون مجامِلون أو مشغولون أو كسالى أو ربما غير مبالين بتقديم أي ملاحظات، وبالنتيجة لا يحصل الفريق إلا على القليل جدًا من الملاحظات بدلًا من سيل الملاحظات المنتظَر.
لا شك أن فريق أجايل بحاجة لجمع ملاحظات المستخدمين وآرائهم بعد الإطلاق، لكن هذا غير كافٍ، إذ يجب أن يعملوا على جمعها أيضًا قبل مرحلة الإطلاق. يمكن إجراء ذلك من خلال عقد مقابلات مع المستخدمين لفهم احتياجات المستخدم ومتطلباته فهمًا أعمق، أو من خلال تقييم الأفكار باستخدام النماذج الأولية المبكرة، أو بإجراء اختبارات سهولة استخدام للتصاميم المحتملة. يمكن أيضًا مطالعة مقال المستخدم ليس دائما على حق للمزيد من المعلومات حول أهمية عدم الاعتماد فقط على ملاحظات المستخدمين في حلول التصميم.
التركيز فقط على الملاحظات الكمية
تميل الكثير من فرق أجايل عند الحديث عن الملاحظات إلى التركيز على الاستخدام أو مقاييس المستخدمين، مثل مدى استخدام الميزة الجديدة، أو أين يتوقف المستخدمون في مسار الاستخدام، أو ما معدل رضا المستخدمين أو صافي نقاط الترويج. صحيح أن هذه الملاحظات الكمية ذات أهمية كبيرة، لكنها تعكس جانبًا واحدًا فقط من الحكاية، فهي تبين ما الذي يحصل دون أن تشير بالضرورة إلى سبب حصول ذلك.
من الضروري أن تعمل فرق أجايل على جمع البيانات الكمية والكيفية على حدٍّ سواء، فالبيانات الكمية مثل المقاييس والمعدّلات تبين للفريق ما الذي يحصل، في حين أن البيانات الكيفية مثل الاستطلاعات النصية ومقابلات المستخدمين ومجموعات التركيز توضّح أسباب سلوك المستخدم. يمكن الاطلاع بهذا الصدد الاطلاع على مقال أفضل خمس طرق اختبار للمستخدم ومقال كيف تحلل ملاحظات العملاء وتجعلها قابلة للتنفيذ لمعرفة المزيد عن كيفية استخدام الملاحظات الكيفية والكمية.
تجاهل الأعباء المالية للتصميم
إذا كانت المنتجات الأصغرية الفعالة MVPs والتكرارات المبكرة والحلول غير المثالية والإصلاحات الفورية ترتّب أعباءً تقنيةً خفية، فإن التصميم السريع في منهجية أجايل يرتب أعباء تصميم ملموسة، مثل اختلاف عناصر واجهة المستخدم من شاشة إلى أخرى، والميزات غير المترابطة التي تؤدي إلى تجربة مستخدم مجزأة، وتعذُّر استخدام نمط التنقل بسبب عدم قدرته على التكيف مع توسع ميزات المنتج.
أمثلة عن أنواع أعباء التصميم التي يمكن أن تتراكم على فرق عمل أجايل.
مثلما يجب أن يضع فريق أجايل خطة للتعامل مع الأعباء التقنية، يجب أن يضع أيضًا خطة للتعامل مع الأعباء المالية للتصميم. قد يتضمن هذا إدخال نظام تصميم للحفاظ على توحيد التصميم، أو تخصيص دورات تطوير للتعامل مع أعباء التصميم، أو استخدام أساليب مثل قصص المستخدم لإعداد خرائط طريق واضحة للتصميم.
تأجيل وضع نظام تصميم
عند إنشاء نسخة مبكرة من المنتج، قد يؤجل فريق أجايل استخدام نظام تصميم إلى مراحل لاحقة، اعتقادًا بأنه لا داعي لإضاعة الوقت في وضع نظام تصميم لمنتج قد يكون قصير الأجل، لكنّ المشكلة هنا أن هذا سيؤدي إلى عدم وضع نظام تصميم على الإطلاق أو إلى الحاجة لمزيدٍ من الجهد في وضعه؛ لأن المنتج سيحتاج إلى إعادة تصميم أو إعادة تكييف ليتلاءم معه.
من الأفضل أن تعمل فرق أجايل على البدء من نظام تصميم مبسَّط أو وضع أساسات له بدلًا من تأجيل المهمة. قد يتطلب ذلك المزيد من العمل على المدى القصير، لكنّ هذا العمل سيثمر حتمًا على المدى الطويل في تسريع التصميم وتسريع التطوير وتحسين الاتساق في المنتج. يُنصح هنا بالاطلاع على مقال كيف تستفيد من أنظمة التصميم لتسريع عملية تصميم المنتجات لمعرفة المزيد عن أهمية وضع أنظمة تصميم في مراحل مبكرة.
خاتمة
أصبحت أجايل الطريقة الأشيع التي تلجأ إليها فرق العمل لتصميم البرمجيات وتطويرها وتسليمها. ومن خلال تجنُّب الممارسات السلبية العشرة المذكورة في هذا المقال بجزأيه، سيضمن فريق العمل تسليم منتجات توفر تجربة المستخدم المنشودة لمستخدميها.
ترجمة -وبتصرّف- للمقالين Agile anti-patterns that can harm a product – Part 1 و Agile anti-patterns that can harm a product – Part 2 لصاحبه Neil Turner.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.