القيم و المبادئ – القيم – Agile Manifesto

مقياس الشغل اللي خلص من أي مشروع بيكون الجزء اللي شغال و جاهز للتسليم (Working Software) مش كود مكتوب و لسه مجربناهوش ولا (design document) ولا (wireframes) ،و كمان الجزء ده لازم يكون (scenario) بيضيف فايدة للي هيستخدم ال(software) ده.

و ده بيخلينا دايما مركزين اننا نخلص شغل جاهز و عدي بكل مراحل التسليم مش بناجل اي مرحلة زي ال(testing) أو ال (integration) في الاخر، و كده ان اللي خلص شغال و مش هيبقى فيه مفاجآت كبيرة في الاخر تخلينا نطول في الوقت أو نيجي على ال (quality).

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

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

و ده بيكون اسمه (Definition of done). و هو الاتفاق عن امتى يكون الشغل خلص، هل لما يخلص (Development)، ولا يخلص (development) و  (functional testing)  و الدنيا شغالة بس فيها (bugs) ولا لما نحل ال(bugs) ولا لما نخلص (security testing).

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

و كمان من ناحية تانية بتظبط التوقعات بالنسبة للوقت، يعني محدش هيقول للفريق انتو مسلمتوش ليه عشان فاهم انهم لسه مخلصوش (Development) في حين أنهم مش هيسلموا غير لما يحلوا ال(bugs) اللي عندهم

ممكن نضيف على ال (Definition of done) اي حاجة الفريق شايف انها لازم تتعمل قبل ما نقدر نسلم للعميل، و ساعة الاتفاق ممكن نتناقش في الحاجات دي لحساب التكلفة مقابل السرعة و حاجة العميل، المهم في الاخر نوصل كفريق لاتفاق نعرف نتعامل على أساسه و في نفس الوقت لا نوقع حاجة العميل محتاجها و مهمة في المشروع ده و لا نعمل حاجة زيادة نقدر نوفر شغلها لحاجات تانية أهم

و عشان نقدر نطلع بال(Working Software) على مراحل، لازم الفريق اللي شغال يكون فيه كل التخصصات اللي تقدر توصل بالشغل انه جاهز للتسليم، و الناس دي بتشتغل مع بعضها طول الوقت و ده اللي بنسميه ال( cross-functional team)

و دي نقطة مهمة جدا لأن من غيرها الشغل هيتعطل علي ما هيوصل لمرحلة ال(done) و بيترتب عليها اننا يكون عندنا حاجات كتير متعطلة لأن الباقيين شغالين و ال (integration) يتأخر و ال(feedback) يتأخر و واحدة واحدة بنخسر مميزات شغل ال(Agile) و نبقى شكلنا بس شغالين (Agile)

من أهم الحاجات اللي بنركز عليها و احنا بنشتغل (Agile) هي التواصل بين الفريق (Individuals and Interactions)، احنا بنقعد و نشرح و نسأل في الشغل اللي هنعمله و بعدين نكتب الكلام ده في (documents) أو (email) عشان يبقى مرجع لأن دي أفضل طريقة لتوصيل المعلومات و ان كل الفريق يبقى فاهم نفس الحاجة ،و عشان كده يفضل يكون الفريق قاعدين في نفس المكان أو متوفرلهم طرق تواصل يعتمد عليها عشان نعلي التواصل الفعال بينهم لأن هو ده

ال Agile في الأساس بيعتمد على الأفراد اكتر من المنظومة، و سهولة التعامل بينهم أساسية عشان بتضمن التطوير المستمر في الشغل و في طريقة الشغل و ان ال( Inspection and Adaption) يكون فعال، فكل ما الفريق كان متحمس و مدعوم من مديرينه و واثقين فيه كل ما كان مسئول اكتر عن الشغل و النتائج و قدر يحسن فيهم اكتر

وأهم حاجة عشان التطور المستمر هو اننا نفحص اللي وصلنا ليه و نطور فيه (Inspect and adapt )،و احنا بنعمل ده على مستوى الشغل لما بناخد بدري (feedback) من العميل و ممثله، و كمان على مستوى طريقة الشغل لما بنقعد كفريق نتاكد اننا بنشتغل بالطريقة الصح و نشوف المشاكل اللي عندنا و نقلها، و دايما ده بيحصل على فترات محددة مثلا كل أسبوعين، يعني المفروض كل أسبوعين يكون عندنا تطور ملموس في طريقة الشغل و التعامل بين الفريق و طبعا فيه إنجاز بس الشغل نفسه و معمول حساب تغييرات العميل.

طبعا من أهم الحاجات في اي مشروع هو التخطيط، بس ببيجي تغييرات من العميل أو من ظروف المشروع أو من الفريق و الخطة بتتلخبط، و مفيش مشروع من غير تغييرات، بس بدل ما نتعامل معاه انه حاجة وحشة عشان هتلخبط الخطة بالعكس احنا ممكن نظبط الخطة انها تقبل التغيير بأقل تكاليف( Responding to change)، في الاخر مصلحة الشغل أهم من الخطة نفسها

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

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

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

كمان عشان نقدر نتعامل مع التغييرات بسهولة، لازم نعمل حسابنا في الشغل من الاول على أننا اكيد هنغير، نبدأ نعمل حسابنا في ال(technical design) أننا نطبق مبدأ (loosely coupled ) و منحطش (design) معقد و كبير في الاول يبقى عقبة كبيرة في الاخر و ده مبدأ ال (evolutionary design)

و مهم جدا كمان ال(unit testing) و ال(testing automation) و ده اننا نبقى عندنا ال(testing) بيشتغل (automatic )على الحاجات اللي خلصانة بحيث اني لو عدلت في حته صغيرة يبقى سهل اتأكد اني مبوظتش حاجة تانية

عشان كده ال(technical excellence) للفريق اللي شغال حاجة مهمة جدا في ال(agile) عشان بيخليهم يبقوا قادرين يشتغلوا على التغييرات بأقل تكلفة و بسرعة

من اسوء الحاجات اللي ممكن تحصل اننا نعمل (Software) محدش بيستخدمه و مش بيضيف أن قيمة للعميل، في الاخر هو كده ضيع فلوسه و كانت تجربته مع الشركة غير مرضية حتى لو الشغل اتسلم في وقته و كويس، و الاسوء بقى لو (Product) للشركة و مش بيحقق الهدف منه، أو اننا نعمل( features) كتير صعبة و معقدة و محدش فاهمها ولا بيستخدمها أو اننا نركز على (module) معين مع ان المستخدمين يهمهم حاجة تانية و احنا سايبينها قديمة و فيها (bugs) و برده مش بيستخدموها.

عشان كده ال(Customer Collaboration) و هو تعاون العميل مع فريق العمل مهم جدا سواء صاحب الشغل أو المستخدم النهائي و خصوصا اننا ناخد منه( Feedback) عن الشغل اللي خلص اول بأول و كمان ننزل ال(scenarios) اللي خلصت اول بأول للعميل حتى لو ده هينتج عنه تغييرات بس في الاخر بيضمن نجاح  اكتر للمشروع و رضا اكتر للعميل لأن العميل ممكن ميكونش متخيل الاستخدام الأمثل للحاجة في أول المشروع غير لما يشوف حاجة جاهزة و يستخدمها و يبدأ يفكر في الاحتياجات الحقيقية و يقول يا سلام لو نزود الحته دي

و ال(Customer Collaboration) مش بس انه يوافق على الشغل أو يعدل فيه، لا هو كمان بيحط أولويات لل(scenarios) الاهم اللي عايزها تخلص الأول و يرتب الباقيين ، و لما بيبقى فيه تغييرات بيشارك في قرار هل نمد الوقت ولا نغير في الأولويات ولا نقسم الشغل لمراحل ، و كمان لو الفريق عنده أسئلة في وسط الشغل بيسألوا العميل أو الممثل ليه في الشركة و المفروض الرد يكون سريع و كافي

و هنلاقي ان القيم دي كلها مرتبطة ببعض و مكملة لبعض ،يعني صعب نقدر نوصل لثقة العميل و انه يكون متحمس لل(Customer Collaboration) غير لو كنا بنقدر نوريله (Working Software) يقدر يحكم عليه و التواصل مع العميل لازم يكون مظبوط ، و صعب نقدر نلبي تغييرات العميل (Respond to Change) و في نفس الوقت نطلع ب(Working Software) من غير ما يكون الفريق متحمس و مفيش مشاكل في التواصل بينهم ولا تاخير في توصيل المعلومات (Individuals and Interactions)