Agile Software Development | AskDeveloper Podcast
Skip to content
AskDeveloperPODCAST
EpisodesTopicsPeopleListen & subscribe

Find a conversation across both shows. Try AI, C#, or a guest’s name.

All episodes
AskDeveloper Podcast
AudioVideo
Published Jun 2, 2013

EP14 - Agile Software Development

Chapters

  1. 00:00مقدمة: تطوير البرمجيات بأسلوب Agile
  2. 01:05مراحل دورة حياة تطوير البرمجيات التقليدية
  3. 02:43نموذج Waterfall ومشكلة المتطلبات المتغيرة
  4. 04:22تقسيم العمل إلى Iterations قصيرة
  5. 08:35حلقة التغذية الراجعة مع العميل
  6. 11:07تقديم قيمة مبكرة بدل بناء بنية غير مستخدمة
  7. 20:51دور Product Owner والتواصل المستمر
  8. 27:34إدارة التغييرات عبر Timebox وIterations
  9. 32:42Agile Manifesto ومبادئ رضا العميل
  10. 36:30الفرق ذاتية التنظيم بدل الإدارة الهرمية
  11. 40:53Retrospective وتحسين عملية الفريق
  12. 49:04تحديات تبني Agile ومقاومة التغيير
  13. 01:04:33Scrum: السبرنتات والأدوار والاجتماعات
  14. 01:12:36Scrum ليس وصفة سحرية: تبني ثقافة Agile
  15. 01:15:55الخلاصة: التحسين التدريجي وجودة التسليم
Product & deliveryProgramming & development
Agile & Scrum

About this episode

يناقش محمد حسام وأحمد الملط تطوير البرمجيات بأسلوب أجايل بوصفه طريقة لتقصير دورة التغذية الراجعة وتقليل مخاطرة اكتشاف سوء الفهم متأخراً. يقارن الحوار بين Waterfall، حيث قد تُجمع المتطلبات وتُبنى أجزاء كبيرة قبل أن يراها العميل، وبين العمل على دورات قصيرة تُنتج في نهايتها وظائف قابلة للاستخدام بجودة إنتاجية. يشرحان Scrum كمثال عملي: قائمة المنتج، السبرنت، الاجتماع اليومي، المراجعة، والاسترجاع، مع التأكيد أن تطبيق الطقوس وحده لا يصنع فريقاً أجايل. كما يتناولان دور مالك المنتج، التنظيم الذاتي، مقاومة التغيير، وخطر تحويل الاجتماعات اليومية إلى تقارير إدارية بلا قيمة.

Discussion highlights

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

Links & resources

  • صفحة AskDeveloper على فيسبوك:facebook.com
  • AskDeveloper على SoundCloud:soundcloud.com
Open on YouTube
IN THIS CONVERSATIONMohamed Elsherif
Mohamed ElsherifHost
Ahmed Elmalt
Ahmed ElmaltGuest
Tamer Zaki
Tamer ZakiGuest

Keep the conversation going.

Ask Mohamed Subscribe to the podcast
KEEP EXPLORING

Continue the conversation.

Episode artwork: EP07 - Data Access - Part 2 - MicroORMs00:42:34
More on Programming & development

EP07 - Data Access - Part 2 - MicroORMs

AskDeveloper Podcast
AudioVideo
Data & databasesProgramming & development
Apr 14, 2013
Episode artwork: EP06 - Data Access - Part 1 - ORMs00:45:06
More on Programming & development

EP06 - Data Access - Part 1 - ORMs

AskDeveloper Podcast
AudioVideo
Data & databasesProgramming & development
Apr 14, 2013
Episode artwork: EP05 - Talking Design - Part 2 - Design Process00:47:03
More on Programming & development

EP05 - Talking Design - Part 2 - Design Process

AskDeveloper Podcast
AudioVideo
Software architectureProgramming & development
Mar 31, 2013
AskDeveloper.

Conversations about software, technology, and the people behind it.

Follow the podcastXFacebook
The Weekend Podcast

Three hosts. A weekly catch-up on tech, news, money, and whatever sparks a good conversation.

Follow the podcastTribbel
About Mohamed Ask the host
SubscribePrivacy PolicyOwner admin
© 2026 AskDeveloper Podcast