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

عشان نشتغل Agile صح يبقي لازم نركز علي قيم و مبادئ الAgile و نفهمهم كويس و نهتم بتطبيقهم في المواقف اليومية في الشغل عشان ناخد اكتر استفادة من الشغل Agile .

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

و القيم و المبادئ دي اتعرفت في ال Agile Manifesto في سنة 2001 لما اتقابل اكتر الناس المهتمين بتطوير مجال software development و تطوير طرق الشغل بهدف اننا نشتغل اسرع و بprocess خفيفة و غير معقدة

القيم الاساسية و الافكار اتكلمنا عليها هنا قبل كده.

بس المبادئ كمان مهمة جدا و فهمها و تطبيقهل بيساعد اننا ناخد اكتر استفادة من الشغل Agile .

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

2. الترحيب بتغيير المتطلبات ولو في مراحل متقدمة من التطوير. فمناهج الأجايل تُسخر التّغيير لصالح الميزة التنافسية للعميل.
و هنا بنركز علي الميزة التنافسية للعميل ،مش بنقبل التغيير عشان هو كده و خلاص ، بس عندنا ميزة اننا نقدر نستوعب التغيير ده في اي وقت لما نكون شغالين Agile صح زي اننا لو عاملين test automation بيكون تكلفة التغيير في اعادة الtesting قليلة جدا

3. تسليم برمجيات صالحة للاستعمال على فترات منتظمة، من أسبوعين إلى شهرين، مع استحسان المدة الزمنية الأقصر.
و هنا نيجي للحاجة المشهورة عن الAgile و هي الiterations ، و ده اننا بنحدد فترات منتظمة نقف و نسلم جزء و نراجع شغلنا ،ودي ميزتها ان الفريق بيكون مركز جدا علي short term release و بيقدروا يسلموها ، و كمان بيسهل اننا ناخدfeedback علي جزء صغير و التغيير بيكون معقول

4. البرمجيات الصالحة للاستعمال هي المقياس الرئيسي للتقدم.
و نرجع تاني و نقول الworking software يا اخوانا..نسلم حاجة خلصانة و جاهزة للاستخدام .

5. يجب أن يعمل كلاً من المهنيين (Business people) والمطورين معاً بشكل يومي خلال فترة المشروع.
و ده مهم جدا عشان سرعة توصيل المعلومات و الرد علي اسئلة الفريق و اتخاذ القرارات
و المقصود هنا بالBusiness people الناس اللي بتقعد مع العميل و فاهمة الBusiness ،ممكن يبقي Business Analyst او Product owner او حد من عند العميل ، المهم يكون علي تواصل دائم مع الفريق ، و المطورين هنا المقصود بيهم الفريق اللي شغال كله
و مع الوقت الفريق بيفهم الBusiness اكتر وطبيعة اللي بيعملوه و بيكتسب خبرة في التعامل مع الBusiness people او حتي العميل نفسه و الاهم من ده بيكونوا عارفين ايه اللي المفروض يعملوه و يركزوا عليه و ايه الزيادة او مش مطلوب

6. الاعتماد في بناء المشاريع على أفراد متحمسين. مع توفير البيئة 
المناسبة والدعم اللازم، ومنحهم الثقة من أجل إنجاز العمل.
احب اركز هنا علي كام كلمة : افراد متحمسين ، الدعم اللازم ، منحهم الثقة
و ده الفرق بين دور الادارة في الAgile و الطرق التانية ، الاعتماد علي الفريق و التواصل بينهم و بين الBusiness people مهم جدا و هم اللي هيعملوا الشغل و هيطوروا نفسهم و شغلهم و دور الادارة هنا التاكد ان مفيش حاجة معطلاهم و انهم ماشيين علي الtrack مظبوط و دعمهم و منحهم الثقة ، علي قد ما الكلام ده يبان بسيط بس مش سهل،هو تحدي للفريق عشان يقدر يشيل المسئولية و ينظم شغله و تحدي الادارة انهم يتصرفوا في المعوقات اللي بتحصل كل يوم و اللي ممكن تكون بسبب افراد تانيين او company policy او ظروف الشغل او موارد قليلة

7. أكثر الطرق فاعلية وتأثيراً لتواصل المعلومات إلى فريق التطوير 
وبين أفراده هي التخاطب وجهاً لوجه.
و دي حاجة في علم النفس عامة مش اختراع في الAgile ، و لو مش متوفر يبقي video call او phone call او حتي chatting ، المهم نركز علي التواصل المستمر

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

9. الاهتمام المستمر بالتفوق التقني والتصميم الجيد يعزز درجة الأجايل.
و هنا بنتكلم عن الtechnical excellence و الgood design علي انها حاجات اساسية عشان نقدر نوصل لاقصي استفادة من شغل الAgile ،لان مع الوقت و تطور المشروع هنلاقي اننا مش عارفين ننجز اسرع عشان فيه مشاكل في الكود او مش عاملين testing automation او اننا مش عارفين ناخدfeedback بسرعة عشان الdeployment process عندنا معقدة و مش automated

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

11. إن أفضل البنيات والمواصفات والتصميمات architectures and designs تنبثق من فرق العمل ذاتيةالتنظيم self organizing teams .
و المبدأ ده مهم جدا و عميق جدا و في صميم شغل الAgile عشان بيتكلم عن ال self organizing teams
مبدأيا دول الteams اللي مش محتاجة متابعة كتير أو micro-management لأنهم بيقدروا ينظموا نفسهم و الشغل بينهم و لو فيه مشكلة بيعرفوا يحلوها أو عارفين يروحوا لمين يحلها أو يساعدهم على حلها مش بيعطلوا
و كمان الself organizing teams بيكونوا فاهمين ال business اللي شغالين فيه و بيكونوا اكتر ناس فاهمين مشروعهم و احتياجاته و كمان بيكونوا اتعلموا الحاجات اللازمة و مركزين على الtechnical excellence زي ما اتكلمنا قبل كده، عشان كده بيطلعوا احسن أو أنسب architecture and design
طبعا مفيش فريق بيتكون من الاول self organizing حتى لو كل الناس اللي فيه شاطرين و عندهم خبرة، لا دي روح أو dynamics بين الناس بتتكون مع الوقت و مع الcommunication الكويس و مع التركيز على inspection and adaption كل فترة، عشان كده بنركز على الفريق و التواصل و اننا نديهم دعم و ثقة عشان نوصل بيهم للمرحلة دي و هم يقدروا يكونوا مسئولين عن الشغل و نستفيد من تجمع خبرات و تفكير 5 أو 8 أفراد مختلفين و متعاونين احسن ما يبقى تفكير مدير واحد
و كل ما الفريق يشتغل مع بعضه اكتر كل ما تعلى درجة الself organizing عندهم، طبعا بيبقى فيه مراحل الفريق لسه بيتكون و بيتعرفوا على بعض و طريقة شغل بعض و دي بنسميها مرحلة forming و بعدها مرحلة بيبقى فيها اختلافات بين أعضاء الفريق و كل واحد شايف طريقته الصح و دي بنسميها الstorming، بعد شوية من الشغل و الinspection And adaption بنوصل لمرحلة الnorming و دي المرحلة أن الفريق بيكون عرف هيتعامل ازاي مع بعضه و مين مسئول عن ايه و مين خبير في ايه و نرجعله و بعدها نوصل لمرحلة الperforming اللي بيكون فيها الفريق بينجز جدا و مش بس بيحل مشاكل لا ده بيحسن من أدائه كمان
و انا في رأيي الفريق لما بيوصل لمرحلة الnorming اقدر اعتبره self organizing و ده ممكن يكون بعد 6 شهور أو سنة مثلا من شغل الفريق ده مع بعض.. و مش مهم هنا يكون نفس المشروع ممكن الفريق يشتغل في اكتر من مشروع ورا بعض
مرحلة الperforming دي طبعا بتحتاج وقت أطول للفريق بس المشكلة اللي بتحصل أن الفرق بتتكسر قبل ما توصل للمرحلة دي، عشان كده احنا لو عايزين نوصل للمستوى ده من الإنجاز يبقى نحافظ على الفريق و نحاول نشغلهم في مشاريع مختلفة ورا بعض مش نقسم و نحط الناس كأفراد تاني.. طبعا فيه challenges زي عدد الفريق و الناس اللي بتتغير بس نحاول نحافظ على القوام الأساسي للفريق قد ما نقدر

الفكرة ان الself organizing مش حاجة بتحصل فجآة ، دي حاجة بتتطور كل شوية ، ممكن في الاول نحط نظام للشغل و يطلع مش صح و نعدل فيه او نغيره ، علي ما نوصل لحاجة مناسبة و نتعود عليها ، و اللي بياخد وقت كمان هي ان الناس تفهم بعض و تتعامل بسلاسة خصوصا لو هتحتاج تظبط attitude معين للناس زي العلاقة الجميلة بين الdevelopers and testers و تتعامل ان الbugs مش خناقة دي مصلحة الشغل ، او العلاقة مع الbusiness و تغييراته و ان الفريق يتقبلها و ان الbusiness يتقبل الوقت اللي هتتعمل فيه

و بيكون دور الleader في الاول مهم ،بيشتغل علي الcommunication و روح الفريق و يساعدهم يحطوا نظام الشغل و يطوروه و يتاكد ان مفيش مشاكل مستخبية واننا بنعمل inspection and adaption صح ، و في الاول مرحلتين ده فعلا ده بيكون مكثف و بعدين بيقل.

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

ممكن يكون documentation اتكتبت بطريقة وحشة و محدش بيقراها و مكملين عليها بنفس الطريقة مع انها مش مفيدة
ممكن تكون company policy او حاجة روتينية بتعطل اكتر ما تنظم و محدش بيحاول يتكلم انها تتغير

بس في نفس الوقت احنا لازم نجرب حاجة و ممكن متشتغلش او متعجبش المستخدم عادي يعني و ممكن نكتب كود و يشتغل غلط و نكتبه تاني من الاول احسن بكتير و اكيد الdocumentation بيكون مفيد بشكل ما ، و اكيد لازم يبقي فيه نظام و policies

عشان كده الكلام هنا ان ده فن – فن تقليص الأعمال غير الضرورية – و اكيد بييجي بالخبرة
بس الفكرة اننا قبل ما نعمل حاجة نسال احنا بنعمل كده ليه و فعلا لازم تتعمل ولا لا و لازم تتعمل بالطريقة دي ولا فيه طريقة احسن
ولازم نقبل اسئلة بعض و نفكر مع بعض ، يعني الفريق يسال هو ليه المستخدم محتاج ال feature دي و ايه المشكلة اللي بنحلها ، و طبعا الclient feedback من بدري مهم عشان نعرف من بدري اهمية الfeature مش لما نخلصها كلها
. ممكن الفريق يتكلم احنا محتاجين مثلا نعمل testing لكل الscenarios دي ولا لا ،طبعا ده بيحتاج فريق متفاهم و بيتقبل الاسئلة دي
ممكن نفكر اننا نكتب الdocumentation من الاول بطريقة تانية تكون فعلا مفيدة ،حتي لو هيكون مجهود اكتر فهو في اتجاه صح .
ممكن نراجع نظام الشغل و الpolicies و نشوف فعلا مناسبة لينا ولا لا … و دي طبعا محتاجة فريق ناضج self organizing و ادارة بتثق فيه و تدعمه

من الاخر لو عايزين نوصل لمرحلة اننا نتقن فن تقليص الأعمال غير الضرورية و نوفر علي نفسنا الوقت و الفلوس و المجهود و نوصل اننا يبقي عندنا self organizing team بيقدر يسلم working software في فترات قليلة و يقدر يطور نفسه من خلال inspection and adaption  محتاجين نطبق الAgile صح و نركز علي القيم و المبادئ و نطبقها و نصبر لما ناخد خبرتها و نطبقها صح

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