أرسلت المبلغ نفسه مجدداً هذا الشهر. وفي نهايته، لا تستطيع أن تُسمّي شيئاً واحداً تم إنجازه. لم يكذب عليك أحد – معظم التطوير البرمجي المستمر يُباع بناءً على التوفر، والتوفر ليس مخرجاً.
التوفر هو الوحدة الخاطئة
معظم الترتيبات الشهرية تُسعَّر كوصول. يُعيَّن لك مطوّر، أو جزء من مطوّر. تحصل على ساعاته، وحضوره على سلاك، وحضوره اجتماعاتك اليومية.
هذا يصمد إلى أن تحاول تدقيقه. لا يمكنك التحقق من ساعات لم تراقبها. لا يمكنك التمييز بين أسبوع بطيء وأسبوع معطَّل وأسبوع خامل. وعندما ينتهي الشهر بشكل سيئ، تكون إجابة المزوّد الصادقة أن الشخص كان موجوداً طوال الوقت – وهذا صحيح، وهو بالضبط المشكلة.
المخاطرة تقع بالكامل عليك. دفعت مقابل أن يكون شخص ما قابلاً للوصول إليه. أما تحرّك قائمة مهامك المتراكمة فلم يكن جزءاً من الاتفاق أبداً. مثل معظم ما يسوء في علاقتك بشركة برمجيات، كان هذا ظاهراً قبل أن توقّع على أي شيء.
كيف يبدو التطوير البرمجي المستمر عندما يكون الإنتاج هو الوحدة
أربعة أشياء تُحدَّد قبل بدء كل مهمة. الأربعة جميعها، كتابياً، في كل مرة.
المختص. شخص محدد بالاسم وله تخصص محدد، مُسنَدة إليه هذه المهمة ويظهر لك اسمه. اختير لأجل الشيء الذي تحتاج بناءه فعلاً.
النطاق. ما تغطيه هذه المهمة، مكتوباً قبل بدء العمل، بينما لا يزال بإمكانك تعديله.
المُخرَج. ما الذي يوجد في موعد الإنجاز ولم يكن موجوداً قبله. مدموج، مُختبَر، ومنشور.
القبول. كيف تؤكد أن العمل قد اكتمل، يُحدَّد في المحادثة نفسها التي حددت النطاق.
لا شيء من هذا غريب أو معقّد. هذه هي الطريقة التي يعمل بها مشروع مُدار جيداً، مطبَّقة على كل مهمة بدلاً من مرة واحدة. هذا الهيكل هو ما يمثّله عقد التطوير المستمر: اشتراك شهري واحد، والمهندس المختص لكل مهمة، وموعد إنجاز لكل واحدة منها.
لماذا يتغيّر الخبير
توظيف شخص واحد يمنحك مجموعة مهارات واحدة. أما قائمة مهامك فلا تبقى على شكل واحد.
المهمة التي تُطلق إصداراً للجوال تحتاج شخصاً سبق أن جادل مراجعي متجر آبل. والمهمة التي تدمج بوابة دفع تحتاج شخصاً تعامل مع تدفق التحقق الآمن ثلاثي الأبعاد (3-D Secure) لدى مصرف مستحوذ خليجي ومطابقة التسويات. وحين تبدأ استعلاماتك بالتأخر تحت حمل حقيقي، لا تريد أياً منهما.
وظِّف مطوّراً واحداً كبيراً وتكون قد راهنت على أن عمل الربع القادم سيتطابق مع أقوى مهاراته. عادة لا يحدث ذلك. العمل ما زال يُنجَز – لكن بشكل أبطأ، على يد شخص يتعلمه على حساب ميزانيتك.
مختص مختلف لكل مهمة هو ما تتطلبه فعلاً قائمة مهام تستمر في تغيير شكلها.
كيف يصمد السياق أمام تغيير الخبير
الخوف منطقي. مع كل تغيير للمختص، يخرج السياق من الباب.
لكنه لا يخرج إلا إذا كان السياق يعيش في رأس شخص واحد فقط.
إذا كان السجل الوحيد لسبب اتخاذ قرار ما هو الشخص الذي اتخذه، فلديك مشكلة في التوثيق. كانت لديك هذه المشكلة قبل أن يتغيّر أي أحد.
ما الذي ينتقل عند تغيير المختص: مدير مشروع واحد يبقى معك منذ اليوم الأول، وسجلات قرارات مكتوبة، وتذاكر مكتوبة بحيث يصمد المنطق وراءها بعد التذكرة نفسها، وسجل تعديلات (commits) يمكن لأي شخص قراءته، وبيئة تُنشَر دون الحاجة لمعرفة ضمنية محصورة بأفراد، ومراجعة من شخص يعرف الكود مسبقاً.
بنينا بوابة العملاء الخاصة بنا جزئياً لهذا السبب – الحالة، والمستندات، وطلبات التغيير في مكان واحد يستطيع العميل فتحه دون أن يسأل أحداً. الاستمرارية التي يمكنك التحقق منها هي النوع الوحيد الذي يستحق الادعاء به. وهو نفس الانضباط التشغيلي وراء بناء تراجعت عنه ثلاث شركات أخرى قبل أن يصل إلينا.
ما لا يُصلحه هذا النموذج
لا يقرّر بدلاً منك. مدير المشروع يستطيع تحويل ما تريده إلى خطة، لكن إذا لم تستطع تحديد ما تريده تالياً، فلن ينتجه شيء. ستكون المهام الأولى هي اتخاذ القرار نفسه.
الاشتراك الواحد يعني مهندساً واحداً في الوقت نفسه. لن ينجز عمل ثلاثة مهندسين معاً.
وهو ليس عملية إنقاذ. الكود الذي في حالة انهيار حقيقي يحتاج أولاً إلى عملية استرداد محددة النطاق، ثم عملاً مستمراً بعدها – تشغيل الاثنين معاً في آن واحد يعني الدفع كل شهر لترميم مبنى ما زال يحترق.
التطوير البرمجي المستمر يستحق الشراء عندما تستطيع الوقوف في نهاية الشهر والإشارة إلى ما وصل. إذا لم تستطع الإشارة إلى أي شيء، فما اشتريته كان تقويم شخص ما.
التوفر ليس هو الوحدة. الإنتاج هو الوحدة.
