الفكرة الرئيسية لإطار عمل سكروم هي تنظيم عملية التطوير من أجل تنفيذ أسرع للعمل في مراحل مختلفة من دورة حياة المشروع. لكن هل يدفع هذا النهج المطورين دائمًا نحو السلوكيات الصحيحة؟ العديد من المستخدمين الذين انضموا إلى مناقشة السؤال أعلاهعلى Stack Overflow ، واجهوا أشياء مماثلة عندما قام المطورون بقطع الزوايا ، أو وضعوا الكثير من التركيز على الدرجات العالية المخصصة لتذاكرهم ، أو حتى التظاهر بأنهم موظفين ذوي أداء عالٍ أمام المديرين. كيف يمكن تجنب هذه الأخطار؟ انتقل السؤال المعني من workplace.stackexchange.com إلى softwareengineering.stackexchange.com . يشير هذا إلى أن المبرمجين ينظرون إلى الاعتبارات المحيطة بـ Scrum وفعاليته على أنها شيء خطير بما يكفي لتجاوز إدارة دورة تطوير البرمجيات. إنهم يشعرون بتأثير طريقة إدارة المشروع هذه على بيئة العمل العامة.
هل سكرم هو سبب ممارسات التنمية السيئة ، أم أنه مجرد ذريعة لهذه المشكلة؟
أثار الكثير من الجدل التكهنات حول تأثير Scrum على الفرق والمطورين الفرديين ، والقيود التي يفرضها إطار العمل على أولئك الذين يستخدمونه. بينما يلقي الكثيرون باللوم على Scrum في فشل الفريق ، يعتقد آخرون أن هذا خطأ في الإسناد وأن جذور المشاكل في فرق التطوير أعمق بكثير.
يرى دعاة سكرم أن الإدارة السيئة هي أصل المشكلة. هذا ما يقوله المستخدم لويلين، بإيجاز: "تتجاهل الإدارة المطورين بشكل أساسي. هناك مواعيد نهائية ثابتة يجب الوفاء بها من أجل تحقيق نتائج محددة مسبقًا. لا يتم العمل بواسطة فريق يركز على تحقيق نفس الهدف ، ولكن بواسطة مجموعة من الأشخاص يهتم كل فرد فيها بنفسه فقط. لا نشجع التخطيط المسبق والتفكير خارج الصندوق. في مثل هذه الظروف ، يستسلم المبرمج نتيجة لذلك للظروف ويجد الخلاص في التنفيذ البسيط للمهام الموكلة إليه. لقد عملت في مثل هذه الظروف. لكن لا تلوم سكرم على ذلك ".
عبر المستخدم DJClayworth عن شعور العديد من التعليقات ، قائلاً إن المبرمجين الذين يعتقدون أنهم يتعرضون للضغط سيؤدون أداءً ضعيفًا مع أي منهجية لإدارة التطوير.
تم التعبير عن الرأي المعاكس في هذه القضية بشكل أفضل من قبل المستخدم مارتن ماعت ، الذي لفت انتباه الجمهور إلى حقيقة أن حقيقة أن الكثير من الناس يشعرون بالحاجة إلى التحدث علنًا بشأن هذه القضية تتحدث عن الإحباط الذي يسبب سكروم.
ما هي المشاكل الشائعة عند استخدام سكرم؟
ظهرت بعض عيوب Scrum الشائعة في التعليقات ، والتي تظهر إما بسبب إساءة استخدام إطار العمل أو لأنها ، في الواقع ، مشكلات متأصلة في Scrum. فيما يلي ما يقرب من اثنتي عشرة مشكلة من هذا النوع لفتت انتباهنا.
▍1. الاجتماعات اليومية للمديرين
يرتبط النقد الأول لسكرم بحقيقة أنه خلال الاجتماعات اليومية (الوقفات) تظهر اتجاهات غير مرغوب فيها. إحدى الحجج المؤيدة لهذه الفكرة هي أن الوقفات يمكن أن تتدهور إلى حالة الأحداث ، حيث لا يفعل المشاركون إلا ما يقولونه بشأن إنتاجيتهم. خاصة إذا كان المديرون حاضرين في مثل هذه الأحداث. لذلك ، دعا المستخدم Matthew Gaiser (الذي كتب لنا بالفعل ، لكننا عثرنا على تعليقه) على أحداث Stand-ups التي تهدف إلى إعلام المديرين بالوضع الحالي ( إدارة التحديث)). وهو يعتقد أن العروض التقديمية للمطورين في مثل هذه الأحداث تشجع المديرين فقط على ملاحظة ما يعملون عليه ، ولكنها ليست مفيدة. هذا صحيح أكثر بالنسبة للفرق الموزعة ، عندما يعمل كل عضو من أعضاء الفريق في وضعهم الخاص.
▍2. يلعب إكمال المهام دورًا رئيسيًا
ظهرت فكرة أخرى في التعليقات وهي أن أي منهجية تطوير تقسم المهام الكبيرة إلى مهام أصغر وتراقب تقدم تلك المهام تؤدي ، سواء عن قصد أو بغير قصد ، إلى مناهج جديدة لتقييم العمل. إذا بدأت للتو في تطبيق بعض المقاييس ، فسيؤثر ذلك على سلوك الأشخاص الذين يتم تقييم أدائهم وفقًا لهذه المقاييس.
يقول العديد من المعلقين إن هذا يعني أن المطورين يمكنهم "قطع الزوايا" لإكمال ما يجب القيام به في السباق الحالي. المشكلة التي أشار إليها المستخدم جايزروالمستخدمين الآخرين ، هي تلك التذكرة المنفصلة التي يتم العمل عليها ، والتي خلال السباق ، يتم نقلها إلى فئة "جاهز" ، وهذا "صندوق أسود". ومهما كان بداخل هذا "الصندوق الأسود" فلن يؤثر على نتيجة تقييم سرعة العمل. كتب User Gaiser أن التنفيذ الرديء الجودة الذي مر عبر قسم ضمان الجودة والتنفيذ الذي تم اختباره وتصميمه بشكل مثالي لا يختلفان عن بعضهما البعض. نتيجة لذلك ، اتضح أن حساب عدد التذاكر المغلقة هو مؤشر غير موثوق به لإنتاجية العمل.
▍3. المطورين المنتجين للغاية الذين لا يعملون كفريق واحد
ناقش موضوع آخر التوتر بين المبرمجين المنفردين العظماء والفرق الرائعة. عندما يتبع الجميع منهجية Scrum ، يمكن أن يكون بعض المطورين منتجين للغاية ، ولكن بعد ذلك يمكن نسيان "الفريق". يقول User Gaiser إنه بدون الحوافز الصحيحة ، فإن التنظيم الذاتي يعد هدفًا بعيد المنال: "سيحل أعضاء الفريق المشكلات على النحو الذي يرونه مناسبًا ، أو وفقًا للتوجيهات. إذا لم يساعد ذلك في بناء الفريق ، فسيتم ترك الكثير دون تحقيق وسيتقدم أعضاء الفريق ببساطة في حالة من الفوضى ".
ويتابع: "علاوة على ذلك ، فإن السماح لكل مطور باختيار طرقه الخاصة لحل المشكلات ، يعني أنه من الصعب تصحيح أخطاء الكود".
▍4. تأجيل المهام الصعبة إلى وقت لاحق
على نفس المنوال ، يواصل جايزر انتقاد وهم الإنتاجية. يقول أنه عند تطبيق Scrum ، يكون التركيز الأساسي على الحصول على التذكرة إلى حالة "Ready". إن التفكير العميق في المهمة في نفس الوقت لا يبدو مثمرًا بشكل خاص. لذلك ، قد يميل المطورون إلى القيام بمهام سهلة وتجنب المهام الأكثر تعقيدًا. هنا ، مرة أخرى ، كلمات المستخدم Gaiser: "يشجع Scrum المطورين على القيام بمهام سهلة تستغرق بعض الوقت لحلها ، مما يسمح للمطورين بإظهار سرعة عالية باستمرار." نتيجة لذلك ، اتضح أن اختيارات المهام اليومية وتقارير العمل اليومية تدفع باختيار المهام التي تستغرق يومًا واحدًا لإكمالها.
▍5. تعتبر ميزات المنتج أكثر أهمية من جودة الكود
يعتقد Gaiser أن استخدام إطار عمل Scrum يؤدي إلى انخفاض جودة المنتج: "عادةً ما يتم تحديد مدى جودة المطور من خلال قدرته على تطوير كود موثوق. Scrum ، ما لم يفهم مالك المنتج البرمجة ويراجع الكود ، فإنه يقلل بشكل خطير من قيمة هذه الخاصية للمشاريع ". ويؤكد هنا أن "جاهزية" التذكرة غالبًا ما يتم تحديدها ليس بعد التحقق من جودة الرمز ، ولكن فقط بعد تنفيذ الميزة المقابلة.
▍6. ضيق الوقت لمناقشة قضايا العمل مع الزملاء
إذا كانت سرعة التطوير هي المؤشر الوحيد لفعالية الفريق ، فهذا يعني أن أعضاء الفريق لم يعد لديهم الوقت لمناقشة بعض القضايا مع بعضهم البعض ، أو للحصول على رأي الآخرين ، أو لاختبار أفكارهم لشخص ما نتحدث عنها. وهذا بالضبط ما يجعل الفريق فريقًا. هنا ، مرة أخرى ، كلمات المستخدم Gaiser: "غالبًا ما يتشاور المطورون الكبار مع المطورين الآخرين ويبحثون عن بدائل لآرائهم. لكن مثل هذه الفصول الدراسية تستغرق الوقت المستغرق لإغلاق التذاكر ، وهذا يؤدي إلى إبطاء سرعة التطوير ".
▍7. البق التي تم تحديدها مؤخرًا يجب أن تنتظر دورها
سلوك سيء آخر لـ Scrum هو أنه "تم العثور على الأخطاء بعد العدو وتعتبر مهام جديدة." يمكن أن يدفع هذا المطورين إلى إصدار تعليمات برمجية منخفضة الجودة ، حيث لا يمكن تضمين مهام إضافية في السباق الحالي.
▍8. العمارة المعتمدة على التذاكر
لا يعتمد نظام التذاكر فقط على المهام التي يختارها المطورون لأنفسهم. يقول User Gaiser أيضًا أن استخدام Scrum ، عن غير قصد ، يؤدي إلى بنية مربكة للمشاريع ، حيث يعمل المطورون على التذاكر بالترتيب الذي تظهر به وبشكل مستقل عن بعضهم البعض. ونتيجة لذلك ، "سرعان ما تصبح الهندسة المعمارية انعكاسًا للتذاكر".
▍9. منهجية إدارة التطوير التي تؤثر على كل شيء على الإطلاق
عند قراءة المناقشة ، يمكنك الانتباه إلى التعليقات ، التي لاحظ مؤلفوها أن أصل جميع المشاكل يكمن في عدم الالتزام الصارم بقواعد سكروم. ومع ذلك ، ربما يكون أقوى ادعاء ضد Scrum من مستخدم Gaiser هو أن الإطار يهيمن على كل شيء آخر. هذا يمكن أن يدمر فريقًا قويًا. "[سكرم] يشوه ويفكك أي آليات أخرى لإدارة التنمية ، يصبح هذا الإطار ظاهرة شاملة لا يتم فيها سوى أداء الطقوس بشكل موحد ، وأداء هذه الطقوس يخلق وهم النجاح."
لقد ناقشنا قائمة طويلة إلى حد ما من المشاكل التي قد تكون ناجمة عن استخدام Scrum ، وربما تصبح أكثر وضوحًا فقط بسبب استخدام هذا الإطار. ولكن في المناقشة التي نجريها ، يمكنك العثور على العديد من الأفكار حول كيفية عيش المطورين في سلام وانسجام من خلال اتباع قواعد Scrum .
كيف تحصل على أقصى استفادة من سكرم؟
كانت العديد من الردود على تعليقات جايزر ، والتي تلقت العديد من التقييمات الإيجابية ، أن ما كان يتحدث عنه لم يكن سكرم. إليك ما كتبه المستخدم Stephen Byrne عن هذا: "أعتقد أن هذه إجابة جيدة مع بعض الأفكار القيمة ، لكن يجب أن أتفق مع العديد من المعلقين الآخرين على أن ما تم وصفه هنا ليس بالتأكيد سكرم ، على الرغم من وينظر إليها تحت ستار سكرم ". لكن الكثيرين إما كرهوا Scrum علانية ، أو اتفقوا مع مستخدم Gaiser على أنه إذا حدث خطأ ما عند استخدام Scrum ، فهذا يعني أن إطار العمل هذا ببساطة لا يتم استخدامه بشكل صحيح.
كيف تستخدم سكرم بشكل صحيح؟
▍1. الاجتماعات اليومية ليست مثل الحصول على تذاكر جديدة كل يوم
قال كثير من الناس إن الاجتماعات اليومية تجبر المطورين على إغلاق التذاكر كل يوم. ولكن ، كما لاحظت DJClayworth ، لا يمكنك الاستغناء عن تحديد أولويات المهام أيضًا. وإذا لم يتم تحديد الأولويات بشكل طبيعي ، فيجب أن يتولى Scrum Master هذه المهمة: "نحن بحاجة إلى ترتيب أولويات المهام ضمن سباقات السرعة ، يجب إعطاء المهام الأكبر أولوية أعلى ، لذلك يجب أن يقوم شخص ما بمهام صعبة في اليوم الأول من العدو. على أي حال ، إذا لم يقم أي شخص بمهمة كبيرة ومعقدة بحلول اليوم الثاني ، يجب على Scrum Master أن يقول شيئًا مثل: "لا أرى أي شخص قد تولى مهمة ضغط قاعدة البيانات. وهذه مهمة كبيرة. إذا كنا سنكمل السباق ، فنحن بحاجة لبدء العمل على هذه المهمة الآن ".
▍2. ,
يجب تقسيم جميع المهام التي يتم حلها في السباق إلى أجزاء صغيرة. هذا لا يمكن إنكاره. لكن إطار عمل Scrum لا يقول أن المطورين يجب أن يكونوا مهووسين بالمقاييس التي تشير إلى النتائج. لا يقترح سكرم تأليب المطورين ضد بعضهم البعض. يقترح User Gaiser التخلي تمامًا عن النظر في نقاط المبرمجين الفرديين. ويشير إلى أن العديد من المديرين قد يحتاجون إلى إعادة تعلم قواعد Scrum: "أخبر المديرين أنه في اللحظة التي يمتدحون فيها المطورين أو يمنحونهم ترقية بناءً على التذاكر المغلقة ، تصبح اللحظة التي يغيرون فيها سلوك الفريق بشكل جذري. ".
المستخدم DJClayworthيوافق على أن التجاهل المتعمد للمقاييس المرتبطة بالتذاكر الفردية يجب أن يكون جزءًا من مهمة Scrum Master الجيد: "يجب تركيز الانتباه على ضمان أن يحقق الفريق أهدافه كفريق واحد. يجب أن يلتزم Scrum Master بهذا السلوك وأن يتجنب أي نقاش أو مقاييس بناءً على عدد قصص المستخدم التي روجها كل عضو في الفريق. "
▍3. تحتاج إلى اتخاذ خطوات صغيرة نحو أهداف كبيرة ، ولكن مع هذا النهج يجب ألا تنسى هذه الأهداف.
إليك فكرة أخرى لتقسيم المشكلات الكبيرة إلى قطع صغيرة: "إذا كنت تعمل على قطعة صغيرة من اللغز ، فهذا لا يعني أنك بحاجة إلى نسيان اللغز بأكمله." يشير
المستخدم Llewellyn إلى أن استخدام Scrum ليس عذرًا لتجاهل مبادئ تطوير البرمجيات عالية الجودة تمامًا: "يجب أن تكون لديك فكرة جيدة عن اتجاه المشروع. يمكن استخدام هذه المعرفة لتخطيط بنية المشروع ، والمشاركة في التخطيط حتى ضمن السباق الحالي ".
لا يحرر Scrum المبرمجين من الحاجة إلى القيام بعملهم ، حيث يضعون كل معارفهم وخبراتهم فيه. لذلك ، تذهب دعوة Llewellyn إلى المبرمجين الذين هم من بين قراء التعليقات: "لقد كنت في الاجتماع ، يمكنك النظر في الأعمال المتأخرة ، وأنت تعرف ما هي الرؤية العامة للمشروع في المنظمة. أنت تسعى جاهدة لتجنب الاضطرار إلى قضاء فترات طويلة من الوقت على شيء من المستقبل البعيد. ولكن لا حرج في وضع الأساس لنظام معياري قابل للتوسعة يكون مناسبًا لحل المشكلات الحالية وسيسمح لك بخلق فرص إضافية مخطط لها بالفعل دون مشاكل في المستقبل. "
▍4. من الضروري تحديد معنى "تم"
كان أحد الموضوعات التي أثيرت في المناقشة التي كنا نناقشها هو تعريف معايير تم (DoD) ، وكيف يساعد تحديد هذه المعايير المبرمجين الفرديين على الالتزام بمعايير جودة معينة والبقاء على دراية بما هو متوقع منهم. كان السؤال الأكثر إلحاحًا هنا هو من كان يطور هذه المعايير ومتى. عندما يتعلق الأمر بـ " متى " ، فعادة ما يتعلق الأمر بتطوير المعايير بأسرع ما يمكن ، أو حول كيفية تطويرها أثناء التخطيط للعدو.
تم كتابة الإجابة على سؤال من ينتج DoD بواسطة المستخدم SpoonerNZ في شكل إجابة لسؤال آخرعلى موقع هندسة البرمجيات. "يتم إنشاء معايير الاستعداد من قبل الفريق ، ولكن هذه العملية قد تتطلب وجود Scrum Master. هذا ضروري من أجل وضع حدود فيما يتعلق بالجودة ، في حالة عدم وجود معايير تطوير واضحة للفريق. على سبيل المثال ، قد لا يرغب الفريق في العبث بمراجعات الكود أو اختبارات الوحدة ، مما سيؤدي إلى إضافة كل هذه إلى DoD بواسطة ScrumMaster من أجل ضمان تطوير عالي الجودة. في وضع مثالي ، بعد أن فهم الفريق نقاط القوة في ما يتم تقديمه ، سيقبله بكل سرور ، لكن العالم الحقيقي ليس دائمًا مثاليًا ".
من يجب أن يعمل بالالتزام بوزارة الدفاع؟ الهدف الطبيعي (والصعب) هو ضمان تطبيق الأحكام الموضحة في وزارة الدفاع في فريق واحد ، ودعمها من قبل جميع أعضاء هذا الفريق. ولكن هناك أسباب وجيهة لتوسيع نفوذ وزارة الدفاع عبر فرق متعددة. أو حتى المنظمة بأكملها. هذا ما يكتبه المستخدم Alan Larimer عنه: "إن عدم وجود تعريف وزارة الدفاع المعترف به عالميًا لمنتج يؤثر سلبًا على جودة وشفافية العمل. يجب أن يكون المستوى التنظيمي لوزارة الدفاع ضئيلًا وتقنيًا وفي بعض الأحيان خاصًا بالمنظمة ، مما قد يوفر تطبيقًا عالميًا لمعايير الاستعداد. يمكن للمنظمة اقتراح معايير للترميز. قد تتطلب المنظمة إنشاء تجميع تلقائي ، مما يوفر الموارد اللازمة لإنشاء التجميعات وصيانتها لكل منتج. أي جزء من وزارة الدفاع ، سواء تم إنشاؤه بواسطة منظمة أو بواسطة مطور فردي ، يجب أن يجلب شيئًا ذا قيمة لمعايير الاستعداد ".
▍5. يجب أن يلعب المديرون دور المراقبين الصامتين
في حين أن ما هو موجود في عنوان هذا القسم منصوص عليه بالفعل في دليل Scrum الرسمي ، فإن تحليل المناقشة يوضح أن هذه القاعدة ، وهي أمر محزن ، غالبًا ما يتم انتهاكها في الاجتماعات اليومية التي يحضرها المديرون. لهذا السبب ، يشعر المبرمجون بالحاجة إلى شرح سبب استغراق وظائف التذاكر وقتًا أطول من المخطط لها. إذا كان هناك مبرمجون فقط يحضرون الاجتماع ، فلا حاجة إلى مثل هذه التفسيرات. وإليك ما يقوله دليل Scrum عن ذلك: "Daily Scrum هو اجتماع داخلي لفريق التطوير. إذا كان شخص آخر حاضرًا في الاجتماع ، فإن Scrum Master يتأكد من أنه لا يتدخل في الاجتماع. "
▍6. يجب أن يكون الناس أكثر أهمية من العمليات
للحصول على إرشادات حول كيفية تطبيق قواعد سكرم ، اقرأ الكلمات التي كتبها المستخدم فرانك هوبكنز لتذكيرك بمبدأ كلاسيكي واحد: "الناس أهم من العمليات." وأضاف إلى ذلك: "يجب أن يحدد الفريق الجيد عملياته ، والعمليات المحددة بدقة لا تسهم في تكوين فريق جيد". أشار
مستخدم آخر ، meriton ، إلى أن استخدام Scrum يعتمد على المبرمجين الفرديين: "لا يشترط Scrum أن يعمل المطورون بشكل مستقل عن بعضهم البعض. ينص سكرم على أن فريق التطوير منظم ذاتيًا ، أي أن الفريق يتخذ قرارات بشأن كيفية تفاعل أعضائه ". ملاحظات
المستخدم nvoigtأن الفرق في Scrum تقوم بالتنظيم الذاتي نظرًا لحقيقة أنها تأتي إلى المشروع بمهمة محددة: "يعتمد إطار عمل Scrum على حقيقة أنك فريق. لا يهم الفريق ما إذا كان قد تم إغلاق التذكرة أمس بواسطة مبرمج معين. أي شخص يعمل في فريق يفهم الهدف (أي وزارة الدفاع) ويسعى لتحقيقه جنبًا إلى جنب مع بقية أعضاء الفريق ".
▍7. قم ببناء فرق للعمل مثل Scrum ، لكن لا تتوقع أن يقوم Scrum بإنشاء فريق
المستخدم nvoigtطبقت استعارة رياضية: "تخيل أن 11 شخصًا تلقوا كتيبًا مطبوعًا لكرة القدم. قيل لهم إنهم بحاجة إلى التدرب في غرفة الاجتماعات رقم 5 كل يوم ، حوالي الساعة 10 صباحًا ، لمدة 15 دقيقة. هل تعتقد أن النتيجة ستكون فريق كرة قدم جيد؟ ماذا لو كان هؤلاء الـ 11 لاعبين محترفين ومحترفين؟ ألن يعمل الأمر على أي حال؟ نعم ، لن يحدث ذلك. كل ما في الأمر أن فرق كرة القدم لم يتم إنشاؤها بهذه الطريقة. مثل أي رياضة جماعية ، يحتاج سكرم إلى أولئك الذين يستخدمون هذا الإطار ليكونوا فريقًا. إذا كانت مجرد مجموعة من الأشخاص ، كل منهم يريد فقط كسب نقاط لأنفسهم من خلال إظهار عدد النقاط في قصة المستخدم التي قاموا بتغطيتها ، أو عدد الأهداف التي حققوها ، فستخسر هذه المجموعة دائمًا لفريق يلعب أعضاؤه معًا ، وليس بجانب بعضهم البعض. صديقأو ضد بعضنا البعض ".
النتيجة
مستخدم nvoigt على استعداد للاعتراف بأن Scrum "غير مناسب تمامًا لجميع الأشخاص أو الفرق." وكما أظهر اهتمام المجتمع بالمسألة التي نناقشها هنا ، فإن تطبيق مجموعة من القواعد التي قد يدفع Scrum لتطويرها يمكن أن يؤدي إلى بيئة عمل بعيدة عما يرغب في بنائه.
نود تلخيص نتيجة هذه المادة بكلمات المستخدم Seth R... يقول ليس هناك حاجة لتوقع المعجزات من طقوس المنهجيات الرشيقة. مطلوب الكثير من قبل أولئك الذين يسعون بمساعدتهم ، كما لو كان ذلك عن طريق السحر ، لتصحيح عيوب فريق التطوير. هذه هي الطريقة التي يرى بها الموقف: "الأمر كله يتعلق بتسريع التغذية الراجعة. نتيجة لذلك ، يتمتع الفريق بفرصة المراجعة الذاتية واتخاذ القرارات حول كيفية العمل لتحقيق أفضل النتائج. لن يساعدك Scrum في إنشاء منتج أفضل ، ولكن إذا كنت جادًا بشأن الاختبار الذاتي ، فيمكن أن يساعدك في بناء فريق أفضل. وهذا بدوره يؤدي إلى تطوير منتج أفضل ".
كثير من الناس يقارنون هذا الإطار بالديمقراطية. إذن ربما سكرم هو أسوأ شكل من أشكال إدارة التنمية ، بصرف النظر عن أي شخص آخر؟
أو ربما يكون ، كما يقول الدليل الرسمي ، إطار عمل يسهل فهمه ولكن من الصعب إتقانه بشكل مثالي.
كيف تجيب على السؤال في عنوان هذا المقال؟
