XP مقابل إدارة المشاريع الجيدة التقليدية [مغلق]

Question

لقد عملت في صناعة تكنولوجيا المعلومات منذ 10 سنوات ولكني عملت في فرق مشاريع مُدارة "تقليديًا" (سواء كانت مُدارة بشكل جيد أو سيئة الإدارة).

لقد سمعت عن نوع إدارة المشاريع "الجديد" scrum أو XP وكنت أتوق إلى أن أكون جزءًا منه (باعتبارنا أشخاصًا نحب دائمًا أي شيء جديد على ما أعتقد) ولكن لم تتح لي الفرصة.

سؤالي هو: ما هي تجاربك في الانتقال إلى الطريقة "الجديدة"؟ هل كانت أفضل أم أسوأ أم لا؟هل كان هناك أي تحسن في معدل نجاح المشروع عند استخدام طريقة XP للتطوير أم أنها مثل أي مشاريع تقليدية تتم إدارتها بشكل جيد؟

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

شكرا لك مقدما

Answer 1

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

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

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

عندما قرأت كتاب XP لأول مرة، اندهشت من مدى دراية "الطريقة التي عمل بها مايك".

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

أعتقد أن المشكلة الحقيقية في إدارة المشاريع التقليدية هي أنها في أغلب الأحيان لا تكون موجودة بالفعل.أنا مندهش من عدد المتاجر التي تدعي أنها تستخدم RUP أو Code Complete أو Agile وليس لديها في الواقع أي شيء يمكن التعرف عليه كإدارة مشروع.بالتأكيد، هناك اجتماعات.ودعا الناس مديري المشاريع.لكن اطرح سؤالاً بسيطًا مثل "ما الذي تم إنجازه في المشروع X" أو "ما الذي بقي للقيام به في المشروع Y" ولا أحد لديه إجابة.يتعين عليهم البحث في رسائل البريد الإلكتروني أو الإشارة إلى ملف مشروع MS غير دقيق بشكل هزلي.

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

Answer 2

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

ولكن، وأنا أقول أن الأمور تحسنت كثيرا عندما بدأنا في سد الفجوة بيننا وبين العملاء. ردود الفعل أكبر وأكثر تواترا والنماذج مع العميل يعني لحظات أقل بكثير من العملاء قائلا: "ليس هذا ما أردت."

Answer 3

لقد استخدمت Scrum (معدل قليلاً) من قبل في العمل وإليك أفكاري:

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

Answer 4

وهذه هي الأجوبة جميلة، ولكن أعتقد أن إدارة المشاريع الخلط بين الجميع مع منهجيات تطوير / تصميم.

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

---

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

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

Answer 9

كان

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

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

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