ليس من المعتاد أن يأتي كتاب إدارة مشاريع البرمجيات عملياً وسهل القراءة ومليء بالنصوص العملية الجاهزة للاستخدام. وهذا ما فعله أندرو ستيلمان وجينيفر غرين في كتاب “إدارة مشاريع البرمجيات التطبيقية”.
إنه كتاب سهل القراءة
هناك الكثير من الكتب التي تتحدث عن إدارة مشاريع البرمجيات أو هندسة البرمجيات الجافة والمعقدة للغاية والمملة، لكن هذا الكتاب ليس واحداً منها. لقد كانت قراءته ممتعة لأن أسلوبهم في الكتابة واضح دون أن يكون مبسطًا ويصف المؤلفون الأشياء بالقدر المناسب من التفاصيل. يبدو أنهما يفهمان جمهورهما وشرعا في الكتابة بطريقة مفيدة وعملية للغاية. وقد حققا ذلك بالتأكيد.
يغطي الجزء الأول من الكتاب الأدوات والتقنيات التي يمكن تطبيقها في المشاريع. تخطيط المشروع، والتقدير، والجدولة، والمراجعات، والمتطلبات، والتصميم، والبرمجة، والاختبار، ولكل منها فصل خاص بها. يدور الجزء الثاني حول استخدام إدارة المشروع بفعالية ويحتوي على فصول حول فهم التغيير والإدارة والقيادة وإدارة مشروع الاستعانة بمصادر خارجية وتحسين العملية.
نصائح عملية للمشاكل
من الخيوط الواضحة في الكتاب وصف المشاكل النموذجية التي تواجهها فرق مشاريع البرمجيات – عدم كفاية المتطلبات، وإدارة التغييرات، ونقص ضمان الجودة في كل مرحلة من مراحل المشروع، ودورات الاختبار وإصلاح الأخطاء التي لا نهاية لها، والتوترات وسوء الفهم بين مهندسي البرمجيات والمستخدمين من رجال الأعمال. ليست أي من هذه المشاكل ذات طبيعة تقنية، بل هي مشاكل تنظيمية وإدارية. يقدم ستيلمان وغرين نصائح عملية لحل هذه المشاكل بناءً على خبرتهما في مشاريع مماثلة.
يبدو أن ستيلمان وغرين يعرفان بالتأكيد الكثير عن المشاكل التي تواجه فرق البرمجيات. ففي بداية المقدمة يصفان الحاجة إلى التغلب على المشاكل المزمنة ويستمر هذا الموضوع طوال الكتاب.
في الواقع، إن المشاكل الأكثر شيوعاً التي تواجهها فرق المشاريع لا تتم تغطيتها بشكل مباشر في دورات إدارة المشاريع النموذجية. لذا، فإن قراءة هذا الكتاب ستزود الفرق ببعض المعرفة اللازمة لتحسين عمليات تطوير البرمجيات الخاصة بهم.
لكل مشكلة، هناك دائماً حل واحد مقترح على الأقل لكل مشكلة. على سبيل المثال، يصفون سيناريو شائعاً حيث لا يثق كبار المديرين بتقديرات الفريق التقني، معتقدين بطريقة ما أن الفريق التقني يتعمد المبالغة في التقدير من أجل منح أنفسهم بعض الوقت للراحة. ويتمثل الحل المقترح في إشراك هؤلاء المديرين في عملية التقدير حتى يتمكنوا من رؤية التقديرات التي يتم إجراؤها بطريقة شفافة ومنهجية. ثم يمضون بعد ذلك في وصف تفصيلي لكيفية تشغيل جلسة تقدير النطاق العريض دلفي ويقدمون أمثلة على القوالب والوثائق التي يمكن استخدامها خلال هذه الجلسات. كما يقدمون أيضاً نصاً قيماً للعملية يمكن للفرق اتباعه.
تغطي الفصول اللاحقة التخطيط والجدولة والمراجعات والمتطلبات والتصميم والاختبار. في حين أن معظم هذه الفصول تغطي كل موضوع بتفصيل معقول، إلا أن القسم الخاص بالتصميم يفتقر إلى التفاصيل ولا يقدم أي وصف لنوع مخرجات التصميم التي يمكن إنتاجها ولا أي وصف تفصيلي لما قد تحتويه مخرجات التصميم هذه. هذا على النقيض من فصل المتطلبات الذي يحتوي على نصوص عملية لاستنباط المتطلبات وتحليلها بالإضافة إلى وصف تفصيلي لحالات الاستخدام ووثائق مواصفات متطلبات البرمجيات.
قوائم المراجعة
جانب آخر لطيف في الكتاب هو قوائم المراجعة التي تظهر بعد تناول أحد الموضوعات الرئيسية لإدارة المشروع أو هندسة البرمجيات. تعد قوائم المراجعة من تقنيات ضمان الجودة المهمة التي يشير المؤلفون بحق إلى ضرورة استخدامها في جميع مشاريع البرمجيات كوسيلة لاكتشاف الأخطاء في وقت مبكر.
على سبيل المثال، إذا تم تطبيق قائمة تدقيق على مواصفات متطلبات البرمجيات واكتشاف أن أحد المتطلبات الهامة مفقود أو غامض، فيمكن تصحيح الخطأ أثناء مرحلة التحليل. ويوضح المؤلفون أنه من خلال اكتشاف الأخطاء وإصلاحها في وقت مبكر، تكون التكلفة صغيرة مقارنة بتكلفة إصلاح الأخطاء التي يتم العثور عليها في وقت لاحق من المشروع. وبالتالي فإن تركيزهم على تقنيات ضمان الجودة التي يتم تطبيقها في جميع مراحل المشروع مع أمثلة لقوائم المراجعة التي يجب تطبيقها هو أمر عملي ومفيد للغاية.
أمثلة
قد يرغب المؤلفون في إعادة النظر في بعض الأمثلة التي يستخدمونها. فهم يصفون عملية إعادة هيكلة التعليمات البرمجية من أجل جعلها أكثر قابلية للصيانة، ويستخدمون مثالاً لبعض التعليمات البرمجية الخاصة بلغة جافا التي يعيدون هيكلتها تدريجياً على مدى عدة تكرارات. في نهاية هذه العملية يقولون لماذا يمكن أن تكون إعادة الهيكلة قابلة للتطبيق في الحالات التي تكون فيها الشيفرة البرمجية شبيهة بالسباغيتي.
كل هذا جيد، إلا أنهم يستخدمون مثالًا لشيفرة جافا غير شبيهة بالسباغيتي لإعادة هيكلتها. من خلال القيام بذلك يبدو لي أنهم يقعون في فخ المبرمجين الشائع لتجميل الشيفرة حيث يقضي المبرمجون وقتًا من الجدول الزمني في تحسين الشيفرة التي تعمل بشكل جيد بشكل متكرر من أجل كتابة الشيفرة أو الفئة أو الكائن “المثالي”. لقد رأيت هذا يحدث في مشاريع لم يكن هناك ببساطة وقت في الجدول الزمني للسماح بذلك، وبالتأكيد لم يجلب أي فوائد إضافية للأطراف المعنية. ومع ذلك فهذه مشكلة بسيطة.
ما ينقصنا
كنت أود أن أرى المزيد من الصفحات المخصصة لإدارة المخاطر. مرارًا وتكرارًا، يتم الاستشهاد بعدم إدارة المخاطر كسبب لفشل المشاريع. يصف المؤلفون إدارة المخاطر بطريقة سريعة، ومع ذلك فإن الكتاب سيستفيد من وصف أفضل لكيفية وسبب إدارة المخاطر في جميع مراحل المشروع، وليس فقط في المراحل الأولى من تخطيط المشروع.
يفتقر إلى الأساليب التكرارية
الشيء الوحيد الذي اعتقدت أن الكتاب يفتقر إلى نظرة مفصلة على الأساليب الرشيقة. الافتراض الضمني طوال الوقت هو أن مشروع البرمجيات يجب أن يتبع أسلوب الشلال. أنا لا أوافق على ذلك. فقد كانت هناك بعض البدائل المهمة لطريقة الشلال التي تم تطويرها على مدى السنوات العشرين الماضية وأبرزها تلك التي تعتمد على الأساليب التكرارية. العيب الرئيسي في نهج الشلال هو افتراض أن كل شيء عن المتطلبات معروف في بداية المشروع.
من ناحية أخرى، تفترض المقاربات التكرارية أن المتطلبات ستتغير خلال المشروع إما لأن المستخدمين يكتسبون فهماً أفضل لما يحتاجون إليه، أو بسبب التغييرات التي تطرأ على بيئة العمل. وبناءً على هذا الافتراض، تم تصميم الأساليب التكرارية لإدارة هذه البيئة المتغيرة بشكل أفضل.
أما في الأساليب الشلالية، فغالبًا ما تتطلب التغييرات في المتطلبات إعادة النظر في المراحل السابقة للمشروع مع زيادة مقابلة في التكاليف والجهد. بالكاد ينفق المؤلفون صفحة واحدة على العملية العقلانية الموحدة (RUP)، وينبغي على المؤلفين أن ينظروا عن كثب في كيفية استخدام نصائحهم وعملياتهم العملية في مناهج تكرارية بديلة للنهج الشلالي.
أهداف واسعة للغاية
أخيرًا، أعتقد أن الكتاب حاول أن يكون واسعًا جدًا من خلال مخاطبة ثلاث مجموعات مختلفة من الناس. أولاً، يستهدف الجزء الأول المشاركين في فريق البرمجيات (مديري المشاريع والمحللين والمبرمجين والمختبرين). أما الجزء الثاني فيستهدف الاستشاريين الذين تم تعيينهم لتحسين ممارسات إدارة المشاريع ومديري المشاريع الذين يحتاجون إلى إدارة مشاريع الاستعانة بمصادر خارجية للبرمجيات. كان من الأفضل أن يكون الكتاب أفضل لو ركز فقط على المشاركين في فريق البرمجيات.
أما الفصل قبل الأخير الذي يتناول إدارة مشروع الاستعانة بمصادر خارجية فيتم التعامل معه بطريقة سريعة كما لو أن المؤلفين شعروا أنهم بحاجة إلى ذكره لأن الاستعانة بمصادر خارجية هي أولوية الأعمال هذه الأيام. كما أن الفصل الأخير الذي يتناول تحسين العمليات قصير للغاية بحيث لا يمكنه التعامل بفعالية مع مثل هذا الموضوع الكبير. كان من الأنسب أن يكون هناك كتب منفصلة تتناول هذه القضايا فقط.
الخاتمة
بغض النظر عن هذه النقاط، يعد هذا الكتاب دليلًا ممتازًا للأشخاص المشاركين في مشاريع البرمجيات، سواء كانوا مديري مشاريع أو أعضاء الفريق التقني على حد سواء. سيجدون الكثير مما يمكنهم تطبيقه مباشرة في مشاريعهم الخاصة.
أوصي بهذا الكتاب لأي شخص يعمل في فريق تطوير برمجيات لأن الكتاب يحتوي على الكثير من النصائح العملية لمساعدة الأشخاص على تحسين قدرتهم على تقديم برمجيات عالية الجودة. وعند التفكير في الأمر، أوصي به أيضًا لكبار المديرين في الشركات الذين لديهم نظرة سلبية تجاه فرق تطوير البرمجيات الخاصة بهم. ربما عندها قد يفهم كبار المديرين لماذا يعد تخصيص الموارد لتحسين العمليات أحد أفضل الاستثمارات التي يمكنهم القيام بها.
إدارة مشاريع البرمجيات التطبيقية | مراجعة الكتاب
About the Author
