قانون بروكس

قانون بروكس هو ملاحظة تتعلق بإدارة مشاريع البرمجيات، مفادها أن "إضافة المزيد من الأفراد إلى مشروع برمجي متأخر يزيد من تأخيره". ^{[ 1 ] [ 2 ]} وقد صاغه فريد بروكس في كتابه "أسطورة الشهر البشري " عام 1975. ووفقًا لبروكس، في ظل ظروف معينة، فإن إضافة فرد إضافي إلى المشروع يزيد من وقت إنجازه، وليس العكس.

بحسب بروكس نفسه، فإن القانون "تبسيط مفرط ومُبالغ فيه" ^{[ 1 ]} ، ولكنه يُجسّد القاعدة العامة. ويُشير بروكس إلى العوامل الرئيسية التي تُفسّر سبب عمله بهذه الطريقة:

1. يستغرق الأمر بعض الوقت حتى يصبح الموظفون الجدد في المشروع منتجين . يُطلق بروكس على هذه الفترة اسم " فترة التأسيس ". مشاريع البرمجيات عبارة عن مساعٍ هندسية معقدة ، ويجب على الموظفين الجدد في المشروع أولاً أن يتعرفوا على العمل الذي سبقهم؛ ويتطلب هذا التدريب تحويل الموارد العاملة بالفعل في المشروع، مما يقلل إنتاجيتها مؤقتًا ريثما يبدأ الموظفون الجدد بالمساهمة بفعالية. كما يحتاج كل موظف جديد إلى الاندماج مع فريق مؤلف من عدة مهندسين، والذين بدورهم يُدرّبونه في مجال خبرتهم في قاعدة البيانات البرمجية، يومًا بعد يوم. إضافةً إلى تقليل مساهمة الموظفين ذوي الخبرة (بسبب الحاجة إلى التدريب)، قد يُساهم الموظفون الجدد سلبًا، على سبيل المثال، إذا تسببوا في أخطاء تُؤخر إنجاز المشروع.
2. تزداد أعباء الاتصال مع ازدياد عدد الأفراد. ونظرًا لتزايد عدد الخيارات المتاحة ، يزداد عدد قنوات الاتصال المختلفة بسرعة مع ازدياد عدد الأفراد. ^{[ 3 ]} يحتاج كل من يعمل على المهمة نفسها إلى التنسيق، لذا مع ازدياد عدد الأفراد، يقضون وقتًا أطول في محاولة معرفة ما يفعله الآخرون.
3. إن إضافة المزيد من الأشخاص إلى مهمة قابلة للتجزئة بدرجة كبيرة، مثل تنظيف غرف فندق، يقلل من مدة المهمة الإجمالية (إلى الحد الذي يعيق فيه العمال الإضافيون عمل بعضهم البعض). ومع ذلك، فإن مهامًا أخرى، بما في ذلك العديد من التخصصات في مشاريع البرمجيات، أقل قابلية للتجزئة؛ ويشير بروكس إلى هذه القابلية المحدودة للتجزئة بمثال آخر: فبينما تستغرق امرأة واحدة تسعة أشهر لإنجاب طفل واحد، "لا تستطيع تسع نساء إنجاب طفل في شهر واحد".

توجد بعض النقاط الرئيسية في قانون بروكس التي تسمح بالاستثناءات وتفتح الباب أمام حلول محتملة. ^{[ 4 ] [ 5 ]}

أولًا، تجدر الإشارة إلى أن قانون بروكس لا ينطبق إلا على المشاريع المتأخرة بالفعل. ^{[ 6 ]} يمكن إعادة المشاريع إلى مسارها الصحيح (أو الحفاظ عليها تحت السيطرة) بإضافة أفراد في وقت مبكر من العملية. ^{[ 7 ]} من المهم أيضًا تحديد ما إذا كان المشروع متأخرًا بالفعل، أو ما إذا كان الجدول الزمني في الأصل متفائلًا بشكل مفرط. تُعزى نسبة كبيرة من حالات تأخر المشاريع إلى أخطاء في الجدولة. يُعد تصحيح الجدول الزمني أفضل طريقة للحصول على إطار زمني ذي معنى وموثوق لإنجاز المشروع. ^{[ 8 ]}

يجب أيضًا مراعاة كمية ونوعية ودور الأفراد المُضافين إلى المشروع. إحدى الطرق البسيطة للتحايل على القانون المتعلق بتجاوز ميزانية المشروع هي إضافة عدد من الأفراد يفوق الحاجة، بحيث تُعوّض القدرة الإضافية تكاليف التدريب والتواصل. ^{[ 9 ]} يمكن إضافة مبرمجين أو متخصصين أكفاء بتكلفة تدريب أقل. ^{[ 10 ]} يمكن إضافة أفراد لأداء مهام أخرى متعلقة بالمشروع، مثل ضمان الجودة أو التوثيق؛ فإذا كانت المهمة واضحة، يتم تقليل وقت الإعداد إلى أدنى حد. ^{[ 11 ]}

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

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

تم اقتراح خطة برمودا ، التي يتم بموجبها إبعاد معظم المطورين في المشروع ("إرسالهم إلى برمودا ") وترك الباقين لإكمال البرنامج، كوسيلة للتحايل على قانون بروكس. ^{[ 12 ] [ 13 ]}

• مسيرة الموت (إدارة المشاريع)
• نمط مضاد
• قانون لينوس
• قائمة القوانين التي تحمل أسماء أشخاص
• قائمة بفلسفات تطوير البرمجيات