لماذا نُسلّم شيئاً كل أسبوع

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

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

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

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