ما هو Agile؟ فلسفة تتطور من خلال الممارسة

نشرت: 2022-07-22

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

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

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

أجايل أسلاف

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

سابقة للفلسفة لتركيزها على التحسين التكراري ، تم تطوير نموذج Plan-Do-Study-Act في ثلاثينيات القرن الماضي من قبل الفيزيائي والإحصائي من مختبرات Bell Walter Shewhart. بعد الحرب العالمية الثانية ، قام ربيبه دبليو إدواردز دمينغ بتطبيقه لتدريب المديرين في شركة تويوتا. كانت هذه الطريقة جزءًا لا يتجزأ من تطوير نظام إنتاج تويوتا ، المصدر الرئيسي للتفكير الليّن مع حلقة البناء والقياس والتعلم الفعالة.

في السبعينيات ، تم تطوير المفهوم بشكل أكبر عندما اقترح Barry Boehm تقنية Wideband Delphi ، باستخدام عملية تكرارية لتقدير العمل والوقت المطلوبين لتطوير البرمجيات بدقة وموضوعية.

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

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

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

يوضح الجدول الزمني النقاط البارزة في تطوير Agile: اختراع Shewhart لـ Plan-Do-Study-Act في عام 1939 ؛ تطبيق ديمينجز للمفهوم في تويوتا عام 1948 ، حيث أصبح فعالاً في إنشاء نظام إنتاج تويوتا ؛ تعميم Boehm لـ Wideband Delphi في كتابه عام 1981 ؛ تقرير تاكيوتشي ونوناكا عن التنمية الموجهة نحو الفريق في مقالهما في عام 1986 ؛ اختراع جيف ساذرلاند لشركة سكرم في عام 1993 ؛ وكتابة "البيان لتطوير البرمجيات الرشيقة" في عام 2001.

ما هو Agile في النظرية؟

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

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

أصبحت مبادئ البيان الآن طبيعة ثانية لمديري المشاريع الرشيقة:

  1. الأفراد والتفاعلات على العمليات والأدوات
  2. منتجات العمل على وثائق شاملة
  3. تعاون العملاء على التفاوض على العقود
  4. وردا على تغيير خلال اتباع خطة

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

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

أصبح تحقيق التوازن المناسب بين العناصر الموجودة على اليمين واليسار هو المفتاح لكيفية توجيه تحويلات Agile. يتجلى ذلك أيضًا في مناهج الإدارة في Apple و Google و Amazon و Facebook و Netflix ، والتي لم يشترك أي منها في إطار عمل Agile واحد. لقد جسّدوا مبادئ البيان أولاً وقبل كل شيء ، أثناء اتباع أو تغيير أجزاء من أطر عمل مختلفة بناءً على ما كان أفضل بالنسبة لهم ؛ ونتيجة لذلك ، تكيفوا مع تغيرات السوق وأصبحوا قادرين على تقديم منتجات جديدة بسرعة.

ما هو Agile في الممارسة؟

في النظرة العامة التالية ، قمت بتعديل الصياغة الأصلية لقيم البيان. تساعد التغييرات في الدلالات على توضيح كيفية تطبيق قيم Agile في الممارسة.

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

الناس على العمليات

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

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

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

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

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

تسليم البرامج على التوثيق

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

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

التعاون على العقود

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

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

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

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

القدرة على التكيف على الأطر

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

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

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

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

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

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

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

سرعان ما أدى هذا النهج إلى زيادة جودة برامج الشركة وتقليل وقت التسليم للميزات الجديدة من أشهر إلى أسابيع.

ما هو مستقبل أجايل؟

خلق جائحة COVID-19 واقعًا جديدًا لم يعد من الممكن أن تتواجد الفرق فيه معًا ، وهي الطريقة المفضلة للعمل داخل Agile عندما تم تصميمه. ومع ذلك ، فإن فكرة أنه يجب أن يظل على هذا النحو هي خرافة: نظرًا لأن العمل عن بُعد أصبح أمرًا شائعًا ، فقد أصبح من الواضح أن الاتصال الوثيق ممكن تمامًا باستخدام برامج مؤتمرات الفيديو. الفرق التي أعمل معها الآن موزعة بالكامل ، وأنا أقدم التدريب عن بعد. حتى أن بعض الفرق تختار العمل بشكل غير متزامن ، باستخدام أدوات مثل Notion و Loom ، بالإضافة إلى مكونات Slack الإضافية مثل Standuply.

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

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