1) متى سيتم تسليم المشروع ؟ أو ما هي تكلفة المشروع ؟?
كمبرمجين،غالبا ما يطلب منا الإجابة على هذه الأسئلة بحكم أننا نملك المعرفة في مجال البرمجيات.لكن هذه الأسئلة وإن بدت بسيطة إلا أنها تحمل العديد من التبعات التي يجب على كل مبرمج أن يعيها جيدا.?
#حزب_المبرمجين
#هندسة_برمجيات
كمبرمجين،غالبا ما يطلب منا الإجابة على هذه الأسئلة بحكم أننا نملك المعرفة في مجال البرمجيات.لكن هذه الأسئلة وإن بدت بسيطة إلا أنها تحمل العديد من التبعات التي يجب على كل مبرمج أن يعيها جيدا.?
#حزب_المبرمجين
#هندسة_برمجيات
2) سأبدا بمثال بسيط وهو تطبيق/موقع فيه خاصية واحدة وهي تسجيل الدخول.
أحد الطرق الشائعة في التقدير هي ربطها بوقت أو مدة ، مثلا "شاشة تسجيل الدخول" تحتاج الى 16 ساعة.
4 ساعات لبناء الواجهة ، 8 ساعات لكتابة ال business logic ، و 4 ساعات أخيرة لكتابة الإختبارات
#حزب_المبرمجين
أحد الطرق الشائعة في التقدير هي ربطها بوقت أو مدة ، مثلا "شاشة تسجيل الدخول" تحتاج الى 16 ساعة.
4 ساعات لبناء الواجهة ، 8 ساعات لكتابة ال business logic ، و 4 ساعات أخيرة لكتابة الإختبارات
#حزب_المبرمجين
3) المشكلة في هذه الطريقة هو أن "16 ساعة" خرجت من مفهوم التقدير وأصحبت Commitment أو Deadline للخاصية?
وبعد مرور يومين عمل -بافتراض ان يوم العمل هو 8 ساعات -سيأتي مدير المشروع أو مالك المشروع يسأل عن التطبيق/الموقع ،وأي تأخير عن اليومين سيعتبر غير مقبول وتأخر في التنفيذ والعمل
وبعد مرور يومين عمل -بافتراض ان يوم العمل هو 8 ساعات -سيأتي مدير المشروع أو مالك المشروع يسأل عن التطبيق/الموقع ،وأي تأخير عن اليومين سيعتبر غير مقبول وتأخر في التنفيذ والعمل
4) المشكلة الأخرى عند التقدير بالوقت هو أنه خلال ال 16 ساعة القادمة ربما لن تستطيع إكمال الا عدة ساعات من المهمة ، فهناك العديد من ال Interruptions والإجتماعات والرسائل التي يجب أن ترد عليها خلال العمل ، وأيضا ربما كان هناك ظرف ما واضطررت الى عدم الإكمال .
5) ما يقوم به البرمجين عندما يتأخر المشروع عن الوقت التقديري ، هو زيادة المجهود والوقت المبذول ، فمثلا بدلا من أن يعمل 8 ساعات ، سيضطر الى عمل 12 ساعة مع الإكمال في اجازة نهاية الأسبوع. ?
#حزب_المبرمجين
#هندسة_برمجيات
#حزب_المبرمجين
#هندسة_برمجيات
6) وبالتالي مع هذه السرعة والضغط الشديد سيضطر المبرمج الى اللجوء الى الممارسات البرمجية الغير صحيحة مثل نسخ الأكواد في العديد من الملفات ، عدم كتابة اختبارات كافية أو عدم كتابتها أصلا ، عدم طلب مراجعة للكود Code Review ، و....الخ ?
#حزب_المبرمجين
#هندسة_برمجيات
#حزب_المبرمجين
#هندسة_برمجيات
7) كل هذا سيؤثر على جودة التطبيق Quality وعلى المبرمج نفسه و على بيئة العمل ككل فهي الآن تعتبر بيئة غير صحية وغير احترافية ، لا تعرف كيف تدير مشاريعها دون زيادة الضغط على المبرمجين ?
#حزب_المبرمجين
#هندسة_برمجيات
#حزب_المبرمجين
#هندسة_برمجيات
8) في حالات كثيرة ربما تكون هناك ميزانية ومساحة لإضافة مبرمج جديد الى المشروع ، لكن:
"إضافة مبرمجين الى مشروع متأخر ستسبب تأخير أكثر في المشروع." وهذا ما يعرف بقانون Brooks . راجع كتابه للمزيد The Mythical Man-Month
"إضافة مبرمجين الى مشروع متأخر ستسبب تأخير أكثر في المشروع." وهذا ما يعرف بقانون Brooks . راجع كتابه للمزيد The Mythical Man-Month
9) منهجيات وأساليب تطوير ال Agile أتت لحل هذه المشاكل ، لكن للأسف الشديد نجد العديد من أصحاب الأعمال والمشاريع يدعون تطبيقهم لل Agile دون فهم صحيح للأسس التي أتت بها هذه المنهجيات وأساليب تطوير البرمجيات. فيكون تأثيرها سلبياُ ?
10) قبل أن أضع الحل لمشكلة التقدير ، دعونا نتحدث قليلا عن أحد أهم الأسس في أساليب التطوير Agile ، وهي ال التخطيط المستمر Iterative Planning ➰
11) على عكس التخطيط المتبع في أغلب المشاريع التقليدية والذي عادة ما تكون قبل بدء المشروع وفيها تحدد جميع الخصائص مع تقديرات مرتبطة بالوقت ، وأيضا يحسب الوقت النهائي للتسليم Deadline. ?
12) في ال Iterative Planning يتم تحديث ال Plan الخاص بالمشروع في نهاية كل Iteration/Sprint (ال Sprint أو ال Iteration هو عادة اسبوعين عمل فيها يختار المبرمج المهام التي يريد أن يعمل عليها)
13) النقطة المهمة هنا هو تحديث ال Plan بناءا على المهام التي تم إنجازها وعلى المهام المتبقية. فمثلا لو عمل المبرمج على مهمة ولم ينجزها كاملة فإنها ستذهب الى ال Sprint التالي مباشرة وسيتم تحديث ال Plan. ?
14) الأساس الثاني في ال Agile هو أن المخرجات ستكون في نهاية كل Sprint وسيتم عرضها لمالك المشروع بالإضافة على عرض ال Plan الجديد ، وهذا ما سيجعل الرؤية واضحة لمالك المشروع وتتيح له تعديل الألويات للمشروع وربما أيضا اضافة خصائص جديدة في المشروع (نعم Agile ترحب بالتعديلات) ❤️
15) نعود الآن الى السؤال السابق ؟ متى ينتهي المشروع ؟ أو كيف يتم تقدير المهام ؟
الطريقة الصحيحة للتقدير هي طريقة بسيطة جدا وهي التقدير النسبي بناءا على المهام الأخرى Relative Sizing ويسمى أيضا التقدير بالنقاط Story points
"الصور من كتاب The Agile Samurai" وهو كتاب أنصح به دائما
الطريقة الصحيحة للتقدير هي طريقة بسيطة جدا وهي التقدير النسبي بناءا على المهام الأخرى Relative Sizing ويسمى أيضا التقدير بالنقاط Story points
"الصور من كتاب The Agile Samurai" وهو كتاب أنصح به دائما
16) الفكرة هنا هو عدم ربطها بالوقت ابدا ، وإنما ربطها نسبيا مع حجم ال effort الذي يجب أن يبذل لانجاز المهام الاخرى.
مثلا اذا كنت احتاج الى 1 نقطة لأكل تفاحة ، فانني احتاج ايضا 1 نقطة لأكل برتقالة ، لكن ربما 10 نقاط لأكل بطيخة.
مثلا اذا كنت احتاج الى 1 نقطة لأكل تفاحة ، فانني احتاج ايضا 1 نقطة لأكل برتقالة ، لكن ربما 10 نقاط لأكل بطيخة.
17)
كأمثلة في المجال البرمجي:
شاشة الترحيب 1 نقطة
شاشة تسجيل الدخول 3 نقاط
شاشة تسجيل حساب جديد 5 نقاط
ال dashboard مثلا 13 نقطة
كأمثلة في المجال البرمجي:
شاشة الترحيب 1 نقطة
شاشة تسجيل الدخول 3 نقاط
شاشة تسجيل حساب جديد 5 نقاط
ال dashboard مثلا 13 نقطة
18) بعد تقييم المهام والخصائص دون الخوض في التفاصيل الدقيقة ، يتم جمع كل النقاط مثلا 700 نقطة
وبعدها يختار المبرمجين المهام في أول Sprint ويبدأ العمل .
وبعدها يختار المبرمجين المهام في أول Sprint ويبدأ العمل .
19) ال Stand-up meeting اليومي هو أحد الطرق الفعالة لجعل الجميع motivated ويعملون دون أي تقصير وذلك بالسؤال عن ماذا فعلت أمس ؟ وماذا ستفعل اليوم ؟ وهل ما اذا كانت هناك أي مشاكل تعيق في العمل ؟
في نهاية ال Sprint يتم جمع النقاط المنتهية مثلا 50 نقطة ، وبالتالي تبقت 650 نقطة .
في نهاية ال Sprint يتم جمع النقاط المنتهية مثلا 50 نقطة ، وبالتالي تبقت 650 نقطة .
20) الفكرة هنا هو حساب ال velocity الخاص بالفريق ، فمثلا اذا كان هناك مبرمجين اثنين في المشروع وكانت مهمة الاول مقدرة ب 30 نقطة والثاني ب 20 نقطة ، فان متوسط سرعة الأول هو 30 نقطة والثاني هو 20 نقطة. ومع استمرار المشروع وال sprints يتم حساب ال velocity بشكل أدق.
21) للأسف الشديد دائما ما ينظر الى جميع المبرمجين على أنهم متساوون في معدل الإنجاز ، و هذا خطأ. فمبرمج بخبرة كبيرة تكون ال velocity أكبر بكثير من مبرمج مبتدئ . وهذا أحد المشاكل التي نقع فيها دائما عند التقدير بالوقت حيث أنها لا تهتم بال velocity وإنما فقط بال deadline.
22) وللتذكير: السرعة في البرمجة ليست كل شيئ ، فربما تكون سريعا في الإنجاز لكن بجودة عمل أقل أو بتصاميم معقدة أو بكود غير قابل للتطوير. وهذا أيضا خطأ شائع نقع فيه حيث دائما يفضل أصحاب المشاريع المبرمج الذي ينجز بسرعة دون معرفة ماذا يوجد بداخل الكود. ?
23) حساب ال velocity مهم جدا ، فهو يعطينا تصور عن متى سيتم إنهاء المشروع دون أن تحتاج الى تعمل بمجهود اضافي تؤدي الى مشاكل في جودة المشروع.
ايضا تعطي مالك المشروع فرصة اتخاذ القرار في وقت مبكر في المشروع. وهذا في رأيي هو جوهر ال Agile. ❤️
ايضا تعطي مالك المشروع فرصة اتخاذ القرار في وقت مبكر في المشروع. وهذا في رأيي هو جوهر ال Agile. ❤️
للمزيد عن Agile :
انصح بقراءة المخلص بالعربي ، للكاتب @WajdyEssam :
كيف تخطط لمشروعك Agile Planning
informatic-ar.com
وايضا الكتب
The Agile Samurai: How Agile Masters Deliver Great Software
Agile Estimating and Planning
بالإضافة الى جميع مؤلفات ومحاضرات @mikewcohn
انصح بقراءة المخلص بالعربي ، للكاتب @WajdyEssam :
كيف تخطط لمشروعك Agile Planning
informatic-ar.com
وايضا الكتب
The Agile Samurai: How Agile Masters Deliver Great Software
Agile Estimating and Planning
بالإضافة الى جميع مؤلفات ومحاضرات @mikewcohn
جاري تحميل الاقتراحات...