لماذا إدارة المشاريع الرشيقة؟
إدارة المشاريع الرشيقة لها تاريخ طويل، ولكننا بدأنا نسمع بهذه المنهجية بشكل متكرر في السنوات الخمس الماضية. بسبب سرعة التغيير المتزايدة للتكنولوجيا وأهمية خفض التكاليف في المشاريع، بدأت مناهج إدارة المشاريع الرشيقة تصبح أكثر أهمية خاصة في مشاريع البرمجيات.
إدارة المشاريع الرشيقة:
تقترح منهجية إدارة المشاريع الرشيقة تسليم منتج أو حزمة عمل إلى العميل على أجزاء أصغر بدلاً من التسليم الكامل في النهاية. وتسمى هذه الأجزاء الأصغر حجماً ب “العدو السريع” وفي نهاية كل عدو، تتاح للعميل فرصة رؤية تسليم قابل للاختبار لبرنامج ما، على سبيل المثال وحدة من شاشة كبيرة. وبما أن أجزاء البرمجيات الكبيرة تتحلل إلى أجزاء أصغر قابلة للاختبار والتحقق منها، فإن هذه المنهجية تمكن من إظهار نتائج عمل المشروع في وقت أقرب مقارنة بالمنهجيات السابقة. يوضح الشكل التالي منهجية إدارة المشاريع الرشيقة في المشاريع.
بدلاً من مديري المشاريع، يقود المشاريع الرشيقة مديرو المشاريع الرشيقة من قبل سكرم ماسترز وهم مسؤولون عن التنسيق والتعاون بين الفريق. يتم تشكيل مجموعات التسليم لكل يوم خلال اجتماعات سكروم التي تستغرق أقل من 15 دقيقة كل يوم. والغرض الرئيسي من هذه الاجتماعات هو إعلام بعضنا البعض “أين أنا في نشاطي”، وكذلك إصلاح مشاكل أعضاء الفريق إن وجدت.
لنفترض أنه في مشروع البرمجيات الخاص بك، لديك شاشة كبيرة جدًا تحتاج إلى تطوير، وتقديرك هو 70 يومًا وتتضمن هذه الشاشة 20 وحدة. إذا كنت تستخدم المنهجيات السابقة، فإنها تعني التخطيط لتطوير هذه الشاشة ككل واختبارها من قبل العميل في النهاية بمجرد أن تكون جاهزة بجميع وحداتها. التغييرات حتمية في المشاريع، وهي أكثر حتمية في مشاريع البرمجيات. 70 يومًا هي مدة طويلة جدًا في عالم البرمجيات حيث يمكن أن تتغير أشياء كثيرة خلال هذه الفترة بما في ذلك:
نطاق الشاشة
متطلبات الشاشة
الأجزاء المترابطة مع هذه الشاشة (مثل الخدمات أو الشاشات الأخرى المرتبطة بهذه الشاشة)
تفضيلات العميل
لذلك، بدلاً من تطوير وتقديم مثل هذه الشاشة الكبيرة ككل قد يسبب مشاكل خاصة في قبول المستخدم أو التحقق من صحة الشروط الأخرى. لأنه، فقط في نهاية الشاشة سيتمكن العميل من التحقق من وظائف الشاشة ومن ثم قبول أو رفض أو طلب التغييرات.
على سبيل المثال، في نهاية الشاشة، قد يأتي العميل بطلب تغيير يؤثر على 6 وحدات من الشاشة ويحتاج إلى يوم واحد من إعادة العمل في كل منها. هذا يعني 6 أيام من إعادة العمل في المجموع.
ومع ذلك، إذا كنت قد اعتمدت منهجية إدارة المشاريع الرشيقة، فسيتم استلام طلب التغيير هذا مباشرةً بعد تسليم الوحدة الأولى من تلك الوحدات الست، وسيتسبب هذا التغيير في إعادة العمل في الوحدة الأولى فقط. سيتم تطوير بقية الوحدات بما يتوافق مع التغيير المطلوب منذ استلام طلب التغيير للوحدة الأولى. وهذا يعني يوم واحد من إعادة العمل في المجموع. ونتيجة لذلك توفير 5 أيام مقارنة بالمنهجيات السابقة.
كما هو موضح في المثال أعلاه، يمكن للمنهجيات الرشيقة أن تتيح تسليم أعمال المشروع بشكل أكثر تواتراً وفترات اختبار وتحقق أقصر، وتقلل من إعادة العمل وتزيد من تعاون الفريق. إذا كنت تتبنى منهجيات رشيقة في مشاريعك، فإن أهم شيء في رأيي هو تجنب زحف النطاق. نظرًا لأن العملاء يرون نتائج متكررة وبناءً على النتائج قد يطلبون طلبات تغيير مفرطة وقد يؤدي ذلك إلى زحف النطاق الذي قد يؤدي إلى فقدان السيطرة على المشروع.
هناك خطأ شائع حول إدارة المشاريع الرشيقة من قبل المنظمات. لقد رأيت حتى في منظمة ناضجة جدًا وشركات تضم أكثر من 10.000 موظف أن “الأجايل” يساء استخدامها من قبل “غير المخطط لها” أو “سريع جدًا”. أتذكر من خلال اجتماعاتنا مع أحد عملائي أثناء بدء المشروع أن أحد المديرين التنفيذيين للعميل قال “ليس لدينا الوقت الكافي للتخطيط؛ نحن بحاجة إلى تسليم هذا المشروع بحلول نهاية هذا العام. لذلك نحن بحاجة إلى إدارة المشاريع الرشيقة”.
يمكن للأجايل أن توفر الوقت في مشاريعك، ولكن هذا لا يعني أنك ستستغني عن التخطيط. سيظل لديك نطاق وميزانية وخطة زمنية وموارد وقيود وما إلى ذلك. قد توفر منهجيات ونهج إدارة المشاريع الرشيقة فقط وقتك، وستوفر الوقت من خلال تقليل إعادة العمل، وتوزيع التحقق من الصحة عبر الزمن، وتفكيك العمل الأكبر إلى أجزاء أصغر يمكن إدارتها وتسليمها. ضع في اعتبارك أنه إذا كان تطوير شاشة ما يستغرق 5 أيام، فلا يمكنك التسليم في 3 أيام من خلال اعتماد منهجيات أجايل. فالجهد المطلوب بذله لإكمال نشاط معين متماثل ويعتمد على النشاط، والمنفذ، والمشروع والقيود الأخرى.
المؤلف : ريسيت غوليك
التاريخ
حول المؤلف
ريسيت غوليك
الفئة