SE201 - دليل شامل لمبادئ إدارة المشاريع
إظهار مهارات إدارة المشاريع من خلال العمل الفعال في فرق صغيرة، والتعاون مع الفرق الأخرى.
إدارة مشاريع البرمجيات هي تخصص حاسم يركز على تخطيط وتنظيم ومراقبة مشاريع تطوير البرمجيات. تضمن إدارة المشاريع الفعالة تسليم مشاريع البرمجيات في الوقت المحدد، ضمن الميزانية، وتلبية معايير الجودة.
تركز إدارة مشاريع البرمجيات الفعالة على أربعة عناصر رئيسية، تعرف باسم الأربع نقاط الأساسية:
العنصر الأهم في المشروع الناجح. يشمل أصحاب المصلحة، أعضاء الفريق، وجميع الأفراد المشاركين أو المتأثرين بالمشروع.
البرمجية المطلوب بناؤها. فهم نطاق المنتج، المتطلبات، والقيود ضروري لنجاح المشروع.
مجموعة الأنشطة الإطارية ومهام هندسة البرمجيات المطلوبة لإنجاز العمل. يشمل منهجية التطوير المختارة.
جميع الأعمال والتخطيط المطلوب لجعل المنتج حقيقة. يشمل الجداول، الموارد، والتسليمات.
يحددون قضايا الأعمال ويوفرون التوجيه الاستراتيجي مع تأثير كبير على المشروع.
يخططون، يحفزون، ينظمون، ويراقبون الممارسين الذين ينفذون أعمال البرمجيات.
يوفرون المهارات التقنية اللازمة لهندسة منتج أو تطبيق.
يحددون المتطلبات ولديهم اهتمام محيطي بالنتائج.
يتفاعلون مع البرمجية بمجرد إصدارها للاستخدام الإنتاجي.
القدرة على تشجيع الأشخاص التقنيين للإنتاج بأفضل قدراتهم من خلال استراتيجيات الدفع أو الجذب.
القدرة على تشكيل العمليات الحالية أو ابتكار عمليات جديدة لترجمة المفاهيم إلى منتجات نهائية.
القدرة على تشجيع الإبداع حتى عند العمل ضمن حدود قائمة.
تؤكد فلسفة الرشاقة على الكفاءة الفردية مقترنة بالتعاون الجماعي كعوامل نجاح حرجة:
فهم نطاق المنتج ضروري لإدارة المشاريع الفعالة. يحدد النطاق ما سيتم بناؤه ويؤسس حدود المشروع.
كيف تتلاءم البرمجية مع نظام أكبر، منتج، أو سياق أعمال؟ ما هي القيود المفروضة نتيجة لذلك؟
ما هي كائنات البيانات المرئية للعميل المنتجة كمخرجات؟ ما هي كائنات البيانات المطلوبة كمدخلات؟
ما الوظيفة التي تؤديها البرمجية لتحويل بيانات المدخلات إلى مخرجات؟ هل هناك خصائص أداء خاصة يجب معالجتها؟
يجب أن يكون نطاق مشروع البرمجيات واضحًا ويمكن فهمه على مستويات الإدارة والتقنية:
التحليل هو نشاط أساسي في تحليل متطلبات البرمجيات، يسمى أحيانًا التقسيم أو تفصيل المشكلة.
يتم تقسيم المشكلة المعقدة إلى مشكلات أصغر وأكثر قابلية للإدارة، مما يوفر فهمًا معقولًا للمعلومات التي سيتم إنتاجها.
نموذج العملية يحدد كيف سيتم تطوير البرمجية. يجب على الفريق اختيار نموذج مناسب بناءً على عوامل متعددة.
اختيار نموذج عملية مناسب
إنشاء خطة مشروع أولية
تحديد مجموعات المهام لكل نشاط
يبدأ تخطيط المشروع بتطبيق العملية على المشكلة. يجب أن تمر كل وظيفة يتم هندستها عبر أنشطة الإطار المحددة للمؤسسة.
وظائف المنتج الرئيسية مثل إدخال النص، التحرير والتنسيق، التحرير الآلي، قدرة تخطيط الصفحة، الفهرسة الآلية والفهرس، إدارة الملفات، وإنتاج المستندات جميعها تمر عبر أنشطة إطار العمل المشتركة بما في ذلك التواصل، التخطيط، النمذجة، البناء، والنشر.
فريق المشروع هو المورد الأساسي!
تقريبًا جميع منتجات البرمجيات يتم الحصول عليها عبر مشاريع ذات موارد محدودة تحقق أهداف مترابطة ومتعارضة.
اهتمام المشروع: التسليم في الوقت المحدد وضمن الميزانية
يتم تتبع التقدم مع إنتاج منتجات العمل (النماذج، الكود المصدري، حالات الاختبار) والموافقة عليها من خلال المراجعات التقنية كجزء من ضمان الجودة.
الوصول إلى جوهر المشروع يتطلب الإجابة على هذه الأسئلة الأساسية:
لماذا يتم تطوير النظام؟ يؤسس المبرر التجاري.
ماذا سيتم فعله؟ يؤسس مجموعة المهام المطلوبة للمشروع.
متى سيتم الانتهاء منه؟ يؤسس جدول المشروع مع توقيت المهام والمعالم.
من المسؤول؟ يؤسس أدوار ومسؤوليات كل عضو في الفريق.
أين هم موجودون تنظيميًا؟ يشير إلى أن المسؤوليات تمتد إلى ما وراء فريق البرمجيات إلى العملاء، المستخدمين، وأصحاب المصلحة.
كيف سيتم إنجاز العمل تقنيًا وإداريًا؟ كم من كل مورد سيكون مطلوبًا؟
من الضروري لمؤسسة البرمجيات تسليم منتج عالي الجودة، مع الحفاظ على التكاليف ضمن قيود ميزانية العميل وتسليم المشروع كما هو مجدول.
هناك عدة عوامل، داخلية وخارجية، قد تؤثر على مثلث القيود الثلاثية. أي من العوامل الثلاثة يمكن أن يؤثر بشدة على العاملين الآخرين.
جدولة المشروع تشير إلى خريطة الطريق لجميع الأنشطة التي يجب القيام بها بترتيب محدد مع تخصيص فترات زمنية لكل نشاط.
التحليل الهرمي للمشروع إلى مراحل، أنشطة، ومهام مع تسلسلاتها. بعض المهام يتم تنفيذها بالتوازي بينما يتبع البعض الآخر بالتتابع.
هدف المشروع (0)
├── المرحلة 1
│ ├── النشاط 2.1
│ ├── النشاط 2.2
│ │ ├── المهمة 2.2.1 (بدائية)
│ │ ├── المهمة 2.2.2 (بدائية)
│ │ └── المهمة 2.2.3 (بدائية)
│ └── النشاط 2.3
├── المرحلة 2
└── المرحلة 3
PDM هي تقنية لجدولة أنشطة المشروع عن طريق عرضها في مخطط شبكي لتحديد المسار الحرج.
| النشاط | المسبق | المدة (أيام) |
|---|---|---|
| أ | --- | 1 |
| ب | --- | 2 |
| ج | --- | 2 |
| د | أ | 4 |
| هـ | ب | 5 |
| و | ب | 4 |
| ز | ج | 6 |
| ح | د، هـ | 6 |
| ط | ز | 2 |
| ي | و، ح، ط | 3 |
المسار الحرج هو تسلسل الأنشطة المتصلة التي تنتج أطول فترة زمنية إجمالية. يمثل هذا الحد الأدنى من الوقت المطلوب لإنهاء المشروع.
مثال المسار الحرج: ب ← هـ ← ح ← ي (المرونة الكلية = 0 لكل مهمة)
| المهمة | البداية المبكرة | النهاية المبكرة | البداية المتأخرة | النهاية المتأخرة | المرونة الكلية |
|---|---|---|---|---|---|
| ب | 0 | 2 | 0 | 2 | 0 |
| هـ | 2 | 7 | 2 | 7 | 0 |
| ح | 7 | 13 | 7 | 13 | 0 |
| ي | 13 | 16 | 13 | 16 | 0 |
| أ | 0 | 1 | 2 | 3 | 2 |
| ج | 0 | 2 | 3 | 5 | 3 |
| د | 1 | 5 | 3 | 7 | 2 |
| و | 2 | 6 | 9 | 13 | 7 |
| ز | 2 | 8 | 5 | 11 | 3 |
| ط | 8 | 10 | 11 | 13 | 3 |
إدارة المخاطر تهتم بتحديد المخاطر التي تؤثر على جدول المشروع أو جودة البرمجية ووضع خطط لتجنب أو تقليل آثارها.
تؤثر على الجدول أو الموارد (مثل فقدان مبرمج خبير)
تؤثر على الجودة أو الأداء (مثل فشل مكون تم شراؤه)
تؤثر على المؤسسة (مثل إطلاق منافس لمنتج جديد)
تحديد مخاطر المشروع، المنتج، والأعمال
تقييم الاحتمالية والعواقب
وضع خطط التخفيف
تقييم ومراجعة بانتظام
| الخطر | النوع | الاحتمالية | التأثير |
|---|---|---|---|
| مشاكل مالية تنظيمية تجبر على تخفيضات الميزانية | تنظيمي | منخفضة | كارثي |
| استحالة تجنيد موظفين بالمهارات المطلوبة | الأشخاص | عالية | كارثي |
| موظفين رئيسيين مرضى في أوقات حرجة | الأشخاص | متوسطة | خطير |
| أخطاء في مكونات قابلة لإعادة الاستخدام تحتاج إصلاح | تكنولوجي | متوسطة | خطير |
| تغييرات المتطلبات تتطلب إعادة عمل كبيرة | المتطلبات | متوسطة | خطير |
| إعادة هيكلة المؤسسة | تنظيمي | عالية | خطير |
| أداء قاعدة البيانات أقل من التوقعات | تكنولوجي | متوسطة | خطير |
| وقت التطوير مقدر بشكل أقل من الواقع | التقدير | عالية | خطير |
| أدوات البرمجيات لا يمكن دمجها | الأدوات | عالية | محتمل |
| العملاء يفشلون في فهم تأثير تغييرات المتطلبات | المتطلبات | متوسطة | محتمل |
تقليل احتمالية ظهور الخطر. على سبيل المثال، التعامل مع المكونات المعيبة من خلال الاختبار والتحقق الشاملين قبل الدمج.
تقليل تأثير الخطر على المشروع أو المنتج. على سبيل المثال، وجود موظفين احتياطيين لمرض الموظفين أو الحفاظ على برامج تدريب متقاطع.
إعداد خطط للتعامل مع الخطر إذا ظهر. على سبيل المثال، تحديد موردين بديلين أو الحفاظ على علاقات مع موظفين متعاقدين.
| نوع الخطر | المؤشرات المحتملة |
|---|---|
| التقدير | الفشل في تلبية الجدول المتفق عليه؛ الفشل في إزالة العيوب المبلغ عنها |
| التنظيمي | نميمة تنظيمية؛ نقص الإجراء من الإدارة العليا |
| الأشخاص | معنويات الموظفين السيئة؛ علاقات سيئة؛ دوران عالي للموظفين |
| المتطلبات | طلبات تغيير متطلبات كثيرة؛ شكاوى العملاء |
| التكنولوجي | تسليم متأخر للأجهزة/البرمجيات؛ العديد من المشاكل المبلغ عنها |
| الأدوات | تردد في استخدام الأدوات؛ شكاوى حول أدوات CASE؛ مطالب بترقيات |