ما هي أهم الأمور التي يجب مراعاتها عند تطوير المشروع؟

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

في هذه المقالة سوف نتحدث عن مجموعه من الأسئلة تحدد الكثير في مشروعك وسوف نطلق عليها Inception Deck ، هي عباره 10 أسئلة وسأقولها لك بكل صراحة: سوف نطلق عليك مجنون اذا لم تقم بسؤالها قبل البدء بأي مشروع برمجي لأنك ببساطة سوف تدمر كل شيء. بعدما تجاوب على هذه الأسئلة سوف ترى  المشروع بشكله الحقيقى أنت وفريقك ومن ثم سوف تبدأ رحلة العمل فيه.

ما الذي يقتل اغلب المشاريع ؟

احد اسباب فشل المشاريع وهي الرؤية المختلفة  للمشروع من قبل اعضاء الفريق ومدراء المشروع، حيث عندما تبدأ المشروع الجديد سوف تجد كل شيء لديه نظرة مختلفة عن المشروع ولديه معاييره الخاصه التي يعتبر المشروع سوف ينجح اذا طبقت :

agile3_2

لماذا النظرة المختلفة تسبب في موت المشاريع ؟  السبب في ذلك هو ان اعضاء الفريق سيعملوا سوية ويستخدموا نفس المصطلحات ولكن سوف يتفاجئوا  فور اول نسخه من التطبيق بأنه شيء مختلف تماماً عن ما يريده الشخص الأخر، لذلك افتراض توافق الفكر بين الجميع هو الذي يقتل المشروع بالتحديد The assumption of consensus where none exists is what kills most

لكي تحل هذه المشكلة، عليك بأن توضح الأهداف goals والرؤية لهذا المشروع لأعضاء الفريق حتى يكونوا بالصورة، وتقوم باعطاء جميع المدراء ومن لهم القرار stakeholders المعلومات اللازمة والتي يمكن ان يقرروا هل يبدئوا أو يوقفوا هذا المشروع.

agile3_3

ولكي تستطيع اعطاء مثل هذه المعلومات فيجب أن تسأل الأسئلة المناسبة  في الوقت المناسب،  وهذا الوقت يكون في بدايه المشروع ، حيث في أي بدايه مشروع سوف تجد هناك العديد من الأسئلة التي تدور في رأسك وتريد معرفة اجابه لها، لذلك قم بسؤال الأسئلة، وحتى الأسئلة العامة Wide-Open Questions قد تفيدك اذا كانت لديك اي استفسارات مثلاً:

ما مدى خبرة الفريق؟ هل سبق ان قمت بشيء مماثل في السابق؟ هل الميزانية كافيه؟ من هو المسؤول عن هذا المشروع؟ هل يكفي وجود محليين وعشرة مطورين؟ ما هي المشاريع التي قمت بعملها مع فريق من المبتدئين Juniors وقمت باعاده مشروع قديم باستخدام Ruby on Rails بفهوم ال Agile؟

agile3_4

الأسئلة التي سنقوم بسؤالها في ال Agile تكون في صميم اي مشروع  حيث لا يمكن البدء بدون الاجابه عنها وسوف نطلق عليها  ال Inception Deck.

agile3_5

ال Inception deck هي مصباحك لرؤية المشروعك بوضوح وتهدف لازالة الرؤية الضبابية ، وهي عباره عن 10 اسئلة ونقاط مهمه للمشروع تحتاج لأن تقوم بسؤالها مع افراد الفريق قبل ان تبدا المشروع،وسوف تصل بعدها لفهم جيد لجميع اعضاء الفريق shared understanding، حيث ستبدأ مع اعضاء الفريق وتقوم بعرض الأسئلة سؤال تلو الأخر وتقوم بتعبئة الاجابه لكل سؤال عن طريق مشاركة الجميع (عرض بوربوينت يكفي، يمكنك تحميل قالب العرض الجاهز للتعديل في اخر المقالة) وهكذا سيعرف الجميع ما هو هذا المشروع، وما الذي سوف يؤديه وكيف يمكن تطبيقه خلال تطوير المشروع.

 أعضاء الفريق في هذا الاجتماع هم من لهم علاقه بتطوير المشروع سواء العميل Customers، المسؤولين Stakeholders اعضاء الفريق team members وهذا يشمل المحللين والمبرمجين والمختبرين وأي شخص لديه اسهام وعمل في تطوير المشروع.

من المهم ادخال المسؤولين في هذا الاجتماع لأن ال Inception deck مفيدة ايضاً لهم حتى يستطيعوا اخذ القرارات المصيرية في هذا المشروع. وفي العاده يمكن الانتهاء من ال Inception deck في عدة ايام الى اسبوعين ويجب مراجعتها دائماً في حال كانت هناك تغييرات جذرية في اتجاه المشروع.

ولأن ال Inception deck لن تكون مجرد ورقه وتضع على الرف بل يمكن ان تضع على حائط كبير حتى تذكر جميع اعضاء الفريق في ماذا يعملوا ولماذا هم يعملوا، وبالطبع الاسئلة ال10 يمكن ان تقوم باضافه ما تشاء اليها من اسئلة تراها مهمه وتحتاج لايضاح قبل البدء لذلك لا تخاف في الاضافة او حتى التعديل لأن فكرة الAgile كلها قائمة على العمل بالشيء المناسب لك.

الأسئلة المهمه Inception deck باختصار:

1)   أسأل لماذا نحن هنا؟ وهذا بالطبع تذكير سريع حول سبب الاجتماع، ومن هو العميل ولماذا نريد بناء هذا المشروع من الأساس

2)  فكرة المشروع باختصار؟ اذا كانت لديك 30 ثانية وفقرتين من الحديث لكي تصف المشروع، فماذا ستقول

3)  تخيل شكل المشروع Product Box اذا قمت بفتح خبر او مجلة أو اعلان في موقع عن مشروعك،  ووجدت الاعلان عن منتجك فماذا سوف يقول هذا الاعلان وهل ستشتريه؟

4)  انشئ قائمة الاشياء التي بخارج حدود مشروعك NOT List: فمن السهل الحديث عن المشروع والجميع يعرف ما هو ولكن بالحديث عن الاشياء التي لم تقوم بعملها فهذا يجعل الفكرة اكثر وضوحاً بكثير

5)  من هم شركاء المشروع او المهتمين Neighbours للمشروع؟ سوف يكون  هناك مهتمين كثر بالمشروع،  فلماذا لا يتم الاجتماع بهم والتعريف بهم.

6)  كيف سنطبق المشروع Solution ؟ وهو مجرد رسم blueprint لهيكلة المشروع حتى تتأكد ان الجميع يفكر في نفس الاتجاه

7)  المشاكل التي قد تواجهنا؟ بالحديث عن هذه المشاكل و كيف يمكن مواجهتها

8)   قدر المشروع فهل هذا مشروع صغير ياخذ 3 شهور ام مثلاً 6 شهور ام 9 اشهر تقريباً

9)  الحديث عن القيود التي لا تتغير المشروع: وهي الوقت والحدود والميزانيه والجودة وما هو الذي يتغير وما هو الشيء الثابت

10)  كم سياخذ وقت لتطوير المشروع وما هي الميزانيه له وما هو الفريق المطلوب

الخمس فقرات من ال Inception Deck هي الأسئلة التي تجيب عن لماذا Why ، بينما الخمس نقاط الأخيرة هي التي تجيب كيف سنقوم بعملها How ، سنبدأ الأن بتناول هذه الأسئلة والنقاط بالتفصيل ولنبدأ بالأسئلة التي  تتحدث عن لماذا؟

agile3_6

السؤال الأول لماذا نحن هنا Why Are We Here ؟

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

السؤال الثاني:  وصف للمشروع بعبارات بسيطة Elevator Pitch

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

بالطبع لا يمكن ان نوحد قالب واحد لكل شيء ويمكن ان تغيره بما يناسبك، ولكن نقاش النقاط من القالب سوف يفيدك في الوصف بشكل جيد:

لمن المشروع For : وهنا سوف توضح الشريحه المستهدفه من هذا المشروع

من يحتاجه Who: والذي يريد هذا المشروع والذي يسوف يفيده في هذا أو يحل مشكلة كذا.

المشروع The: ابدء حياة مشروعك من الأن بوضع اسم عليه وهذا مهم لأنه وسيلة في التخاطب وسوف يسهل عليك فيما بعد .

وهو Is a: تصنيف المشروع أو الخدمه او المهمه التي سيقدمها المشروع

الذي That: تحدث عن ميزته والتي ستجعل العميل يود شرائه مباشره فور رؤيته

بعكس Unlike : المنافسين وتحدث لماذا لا نستخدمهم

مشروعنا Our Product: سوف يقوم بهذا وتلك  (تحدث عن الميزة أو الفارق عنهم) والتي سوف تميزك عن المنافسين

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

كيف تنشى ال Elevator Pitch مع الفريق؟  يمكنك ان تقوم بطباعه القالب وتجعل كل شخص يقوم بتعبئته قبل الاجتماع، أو يمكنك ان تحفظ الوقت وتبدأ الأجتماع ومن ثم تقوم بفتح القالب في شاشه عرض وتقوم مع الفريق بتعبئة القالب والاجابه على كل فقرة منها. هكذا اصبحت لديك نبذه المشروع المختصرة، لننظر الأن لشكل المشروع الخارجي.

السؤال الثالث: كيف سيبدوا المشروع Design Product Box

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

اعصر عقلك مع الفريق واخرج الفوائد من المشروع Brainstorm your product benefits: فلا تخبر العميل او المستخدمين عن المزايا Features في المشروع فهم لا يهتموا بها، الشيء الذي يجعل المستخدمين يهتموا بالمشروع هو الامر الذي يجعل حياتهم اسهل من خلاله، وبعباره ابسط فوائد المشروع.

مثال على ذلك، مثلاً اردت تريد بيع كاميرا رقمية بدقة 24 ميغا بكسل، فاذا جائك زبون لا يعرف شيء عن مواصفات الكاميرات ولا شيء فعندما تقول له هذه ب24 ميغا سوف يكون جوابه “وبعدين” لأنه لا يفهم ذلك، يمكنك كسب الزبون بتحويل ال features الى benefit بذكر سوف تستطيع تصوير بجودة عالية والصور سوف تكون واضحه ، وهكذا حولتها الى فوائد قد يقرر العميل شرائها اذا علم انها تفيده.

اختر العباره الرنانة لمشروعك Create a Slogan: والذي سيحمل الكثير بمجرد ذكر الاسم، مثلاً ستجد كثير من الأوصاف التي تأتي مع الاسماء التجارية ، مثلاً:

Acura—The true definition of luxury. Yours.

FedEx—Peace of mind.

Starbucks—Rewarding everyday moments

فيمكنك اختيار (اسم البرنامج – الوصف السهل المناسب له) ، يمكنك المحاولة  مع اعضاء  الفريق وقم بعمل اجتماع لمدة 10 دقايق فقط time boxing لاختيار الوصف المناسب لمشروعك . هكذا تكون خرجت باسم المشروع وفوائده مع وصف بسيط له

السؤال الرابع: المهام الخارجة عن نطاق المشروع Create Not List

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

ويمكن ان تقوم بها مع جميع افراد الفريق وايضاً مع العميل ومحاولة عصف الذهن جيداً لكي يتم معرفة ما ستقوم به وما الذي يعتبر خارج نطاق المشروع، ويمكن عمل قائمة من 3 خانات: المهام الداخلة في نطاق العمل IN والتي سوف تعمل عليها وهي بشكل عام جداً high level مثلاً سوف يحتوي المشروع على خاصية التقارير، أو له اداء عالي وقابل للزياده Scalability، القائمة الثانية وهي للمهام الخارجة من نطاق المشروع OUT او التي سوف تكون في النسخ التالية Next Release واي مهمه لا تهتم بها ضعها هنا، القائمة الثالثة وهي للمهام التي تحتاج اخذ بعض القرارات Unresolved وهي مهمه لأنه في الواقع سوف تجد ان هناك اشياء تحتاج لبعض الدراسه او اخذ القرار بعملها او لأ بناء على المتطلبات والقيود في المشروع، وفي الأخير كل المهام التي في هذه القائمة سوف تذهب اما للمهام الداخلة في نطاق المشروع IN أو الخارجه حالياً عنه OUT.

السؤال الخامس:  التعرف على أعضاء الفريق Neighbours:

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

تعرفنا الأن على نقاط  لماذا Why ولنكمل الحديث حول الجزء التي يصف كيف يمكن How، وسنبدأ بوضع بعض النقاط في هذا الموضوع، حيث سنقوم بعرض الطريقة التي سنحل بها المشكلة بشكل تقنى ونتحدث عن المخاطر التي قد تواجهنا مع محاولة تقدير الوقت الزمني للمشروع، ولنبدأ بالحل التقني

النقطة السادسة : قم بوضع تركيبة المشروع Technical Architecture:

وضع اليه عمل المشروع بشكل مرئي Visualization سوف يفيد جميع اعضاء الفريق حيث سيدركوا كيف سيتم بناء هذا المشروع، لذلك الحديث عن المشروع مع الفريق مهم لأنه سوف يحدد التقنيات والادوات واللغات التي سوف تستخدم في المشروع، وايضاً سوف يوضح الافتراضات حول حدود المشروع Scope بالاضافه الى انه يوضح المخاطر Risk اذا تواجدت في المشروع .

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

وهنا عليك بالاجتماع مع اعضاء الفريق التقنيين وتبدؤا بالحديث عن كيفية بناء هذا المشروع، وتبدأ بوضع الرسم التي تحدد المعماريه مع فريقك Architectural Diagram وحاول معرفة اي احداث جانبية (ماذا سيحدث اذا حصل كذا) مع فريقك حتى تصلوا لمعرفة حجم المشروع الحقيقي ومدى تعقيده، ايضاً اذا كانت هناك أدوات أو مكتبات مساعده يمكنك الحديث فيها اذا كانت ستفيد في العمل (ويمكن مثلاً الحديث عن رخص المكتبات المسموحه بها أو التي لا يسمح بها ان كنت تعمل ضمن قيود معينة)، هكذا تكون قد كونت الحل المبدئي للمشروع ولتنظر في المخاطر Risks المحتمل حدوثها في المشروع.

النقطة السابعة : مخاطر المشروع  Project Risks:

هناك العديد من الأشياء يمكن ان تكون مسببة لأي مشكلة في المشروع، مثلاً قد تكون التقديرات الزمنية Estimation ليست جيدة كفايه، أو ان يكون العميل (وهم كذلك) يغير متطلباته بشكل متكرر كثيراً وغيرها من الأشياء التي تجعلك تقوم بالعمل اكثر من الوقت والميزانية الموجودة ، وهذه الأمور هي مخاطر المشروع Risks.

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

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

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

النقطة الثامنه : تقدير المشروع Timeline

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

agile3_20

سيتم الحديث عن كيفية التقديرHow To Estimate في المقالة التالية ان شاء الله ، لذلك سنفترض الان انك قمت بعمل الخطوات وقدرت المشروع مع الفريق والأن سوف تعرض النتيجة هنا، ولكن للتذكير يجب ان تقدر في حدود مغلقة وليست مفتوحة Open-Ended فالمشاريع الكبيرة المفتوحة قد لا تنتهي ولا تسلم اصلاً، لذلك في الAgile يفضلوا التقديرات الصغيرة والتي يستطيع ادارتها والتعامل معها وهي بشكل عام سته اشهر وكل ما زاد عن ذلك كلما كانت هناك مخاطرة.  وبالطبع التقدير يكون شامل لكل شيء سواء الاختبارات والتدريب لو تطلب المشروع وكل ما هو مطلوب لتشغيل المشروع.

من الضروري تذكر ان هذا التقدير هو تقدير في النهايه، وقد يأخذ المشروع وقتاً اقل أو أطول من ذلك، وعلى العميل ان يدرك ذلك، فهذا ليس وعد بالتسليم Commitment ، وهذه التقديرات سوف تعرف حتها وقتما تبدأ بالمشروع وفي خطواتك الأولى وحينها تستطيع القياس بشكل دقيق جداً.

النقطة التاسعة : كن دقيقاً في معرفة ماذا ستقوم به:

هناك بعض الأمور الثابته التي لا تتغير بسهوله في اي مشروع، مثلاً الميزانية Budget والوقتDates  دائماً ثابتين ، وفي المقابل تجد المشروع يتوسع مع الوقت Scope Increasing والجودة الجميع يريدها اعلى شيء يمكن، لكن في العالم الحقيقي الأمر ليس بهذا الشكل فكلما تعطي معامل اهمية ستجد أن هناك تقليل في المعامل الثاني، السؤال هو ما ذلك العامل؟

قبل أن نجيب على ذلك، قم بالجواب على كل من هذه الأسئلة :

1) ما هو الشيء الأكثر أهمية في المشروع ؟

الجودة Quality

الوقت Time

حدود المشروع Scope

الميزانية Budget

2) عندما تصادف الكثير من المهام ولديك وقت قليل فماذا تفعل ؟

قلل حدود Scope المشروع أو ال Features فيه

اضف مزيداً من المبرمجين للمشروع

غير وقت تسليم المشروع Release Date

انجز بدون الاهتمام بالجودة

3)  ما هو الشيء الأكثر الماً painful ؟

المشى فوق النار

اكل الزجاج  المكسر

اخبار الراعي Sponsor او صاحب المشروع بأنك بحاجه للمزيد من المال

بعد النظر لهذه الأسئلة وفهمها، قد تجد ان الجواب هو قد يعتمد it depends على عدة أمور ولا يوجد جواب قطعي، ومن هنا يجب الحديث حول الأمور الأربعه الاساسية في المشروع، وهي الوقت Time والميزانية Budged والجودة Quality وحدود المشروع Scope .

agile3_23

الوقت Time عامل مهم حيث هو محدود ولا يمكن استرجاعه، لذلك يجب بذل ما تستطيع في الوقت المتاح لك، وهكذا مستخدمي ال Agile يجب ان يفضلوا المهام المحدودة time-boxing لأن تأخير الوقت والتسليم قد يشكك العميل في العمل بالاضافه الى انك قد تتأخر ولن تسلم المشروع من الأساس وهذا أسوء شيء يمكن ان بكون في المشاريع.

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

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

حدود المشروع Scope فالأن لدينا الوقت Time والميزانية Budget والجودة Quality كلهم ثابتين، لكن لديك الورقة الأخيرة للتفاوض وهي حدود المشروع، فاذا كان هناك الكثير فيمكن انجاز معظم المهام منها أو التي يمكنك انجازها في الوقت المسموح، فاذا تعارض الواقع مع الخطة فعليك بتغيير الخطة، ربما قد يظن البعض بأن الخطة غير قابلة للتغير ولكن في الواقع الأمر كذلك.

يمكنك الأن الحديث مع العميل ومحاولة فهم ما يهمه هو في المشروع فربما لديه معايير، باستخدام هذا الشريط  Trade-off Sliders  يمكنك معرفة ذلك بسهوله:

agile3_24

بالطبع لا يمكن ان أن تكون كل الاجابات بنفس الدرجة أو حتى اجابتين بنفس الدرجة، فالفكرة هنا معرفة مدى اهمية العامل مقارنة بغيره، ولكن هذا لا يعني ان العامل الثاني غير مهم:

agile3_25

agile3_26

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

agile3_27

هكذا تكون قد قمت بمعرفة ما يدور في فكر العميل، وبقى ان تعرض كيف سيطور هذا المشروع والمراحل التي فيه.

النقطة العاشرة : مراحل تطوير المشروع Releases

الى هذه النقطة اصبحت لديك رؤية جيدة للمشروع، وقمت بعمل التقدير الزمني له لذلك تستطيع الان القيام بتقدير التكلفة له، مع ايضاح مراحل العمل على المشروع،  وايضاً معرفة الفريق الذي سوف تحتاجه في  العمل معك، ولنبدأ بالفريق،

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

agile3_28

بعد ذلك عليك التعرف على من له الكلمة العليا فلا يوجد ما يزعج المبرمجين وجود اكثر من شخص وكل منهم له اراء مختلفة عن الاخر ، لذلك تحديد هذا العميل او صاحب المشروع والذي يكون له المرجعيه امر مهم ايضاً:

agile3_29

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

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

agile3_30

هكذا نكون قد غطينا ال Inception Deck بشكل موجز، وهكذا تكون عرفت المشكلة لديك ، والفريق وهذه هي نقطة البدايه في المشروع، والان الجميع يعرف لماذا سوف تقوم ببناء هذا المشروع،  ومن هم اعضاء الفريق وكيف سيبدوا المشروع والمخاطر في المشروع، وما هي القيود التي لا تتغير في المشروع، والتقدير للوقت والتكلفة للمشروع.

الأن انت جاهز للبدء في التخطيط للمشروع Agile Planning ، وسوف نتحدث عنها في المقالة التالية ان شاء الله وسنتحدث بها عن التقدير Estimation وكيفية انشاء قائمة المهام للمشروع، وبعض الأمور الأخرى كالحديث عن سرعه انجاز الفريق للعمل، فالى لقاء قريب.

القيود الثلاثة : الوقت , التكلفة و النطاق