قصة Kent Beck في Facebook وما تعلمه صاحب TDD هناك

إذا بحثت عن اسم Kent Beck مع Facebook فسوف تجد عنواناً يتكرر في المدونات والمنتديات وهو «Kent Beck fired from Facebook»، أي أن صاحب البرمجة المتطرفة Extreme Programming وصاحب منهج التطوير المقاد بالاختبارات Test-Driven Development، واختصاراً TDD، طرد من Facebook. والعنوان صحيح في كلمة واحدة قالها Beck بنفسه، ولكنه يخفي قصة أطول وأهم بكثير: مهندس معروف عالمياً يدخل شركة لا يهتم أحد فيها بكتبه، فيقرر أن ينسى ما يعرفه ويتعلم من جديد، ويخرج بعد سبع سنوات بنموذج يشرح كيف تدار المشاريع في مراحلها المختلفة، ثم يختلف مع الشركة على الطريقة التي تقيم بها موظفيها.

وقد كتب Beck بنفسه أن TDD ثم JUnit ثم Extreme Programming كانت أعماله الناجحة قبل Facebook، وهو أيضاً أحد الكتاب السبعة عشر لبيان Agile المعروف بال Agile Manifesto. ولهذا فإن قصته في Facebook ليست قصة موظف عادي، وإنما قصة شخص بنى سمعته على طريقة معينة في العمل ثم وجد شركة ناجحة جداً تعمل بطريقة أخرى.

وسوف نناقش في هذا المقال ما يلي:

• متى دخل Beck إلى Facebook ومتى خرج، وما الذي يمكن إثباته من التواريخ.
• ماذا وجد عندما وصل، وقصة درس TDD الذي لم يسجل فيه أحد.
• كيف كانت Facebook تعمل بسرعة مع عدد قليل من اختبارات الوحدة Unit Tests، وما الشرط الذي يجعل ذلك ممكناً.
• كيف تحول من مبرمج يحصل على تقييم سيئ إلى مدرب للمهندسين.
• نموذج 3X الذي يقول إنه احتاج خمس سنوات ليراه.
• السياق الكامل لعبارة «I got fired»، وما الذي لا نعرفه عنها.
• الدروس للمهندسين والمديرين.

والقصة هنا بكلام Beck نفسه، من مقابلته مع Software Engineering Daily سنة 2019، وحلقة Being Human التي سجلها بعد خروجه سنة 2018، ومقالات نشرته البريدية.

كيف وصل Beck إلى Facebook؟

يقول Beck في مقابلة Software Engineering Daily إنه تلقى في نهاية 2010 اتصالاً من موظف توظيف في Facebook، فذهب إلى المقابلات ورأى ثقافة هندسية مختلفة عن كل ما رآه من قبل، وكانت آخر مقابلة في ذلك اليوم مع Mike Schroepfer، فقال له إن هذه الثقافة فريدة ولكن المحافظة عليها وتطويرها سوف تكون عملاً صعباً، وإنه يريد أن يأتي ليقوم بهذا العمل، أي أنه قدم نفسه في البداية على أنه حامل للثقافة ومراقب لها، وليس مبرمجاً فقط.

وقد يتساءل البعض: لماذا تحتاج شركة ناجحة إلى من يحمي ثقافتها؟ والإجابة في كلامه أن الشركة كانت عندها قرابة 2000 موظف منهم 700 مهندس، وكانت سوف تكبر بسرعة وتوظف أناساً من Google وMicrosoft يحملون قيماً وممارسات مختلفة، والميل الطبيعي في هذه الحالة هو العودة إلى المتوسط: تخطيط أكثر ودورات أطول وتسليم بين الفرق ودفعات أكبر، وهي أشياء يقول إنها منطقية على المدى القصير والحجم الصغير ولكنها تقتل الفعالية على المدى الطويل.

بدأ Beck العمل في Facebook في أوائل 2011، وبقي فيها سبع سنوات حتى ربيع 2018، فدخلها وفيها قرابة ألفي موظف وخرج وهي قرابة خمسة وعشرين ألفاً، ثم انضم بعدها إلى شركة Gusto.

والصورة التالية تبين المحطات التي سوف نمر عليها:

درس TDD الذي لم يسجل فيه أحد

كل مهندس جديد في Facebook كان يمر بمرحلة تسمى Bootcamp، وفي أول هاكاثون Hackathon حضره Beck كان يمكن لأي موظف أن يسجل ليقدم درساً، فقرر أن يقدم درساً في TDD، والسبب كما يقول بسخرية من نفسه أن لا أحد هناك يستخدم TDD، فبكل تأكيد سوف يريدون أن يتعلموا منه. ثم يحكي ما حدث في قائمة التسجيل:

• الدرس الذي قبله في القائمة كان عن تقنيات متقدمة في Excel، وكان ممتلئاً وعليه قائمة انتظار.
• الدرس الذي بعده كان عن رقص التانجو الأرجنتيني، وكان ممتلئاً أيضاً وعليه قائمة انتظار.
• درسه هو لم يسجل فيه أحد، أي صفر.

ويقول إنه عاد قبل أن يغادر الشركة إلى الويكي القديم ووجد الدليل ما زال هناك. والمهم في القصة ليس الطرفة، وإنما القرار الذي اتخذه بعدها، فقد قال: «I deliberately chose to forget everything I knew about software engineering»، أي أنه اختار عن قصد أن ينسى كل ما يعرفه عن هندسة البرمجيات، وأن يعمل مبرمجاً يراقب ما يفعله الآخرون وينسخه: إذا قالوا إن التغيير يحتاج اختبارات كتبها، وإذا قالوا لماذا تكتب اختبارات هنا لم يكتبها. والسبب الذي ذكره أمران: أن هذه هي الطريقة الوحيدة لفهم لماذا تنجح هذه الطريقة في العمل، وأنها الطريقة الوحيدة ليكون له تأثير، لأن أحداً لن يسمع له بسبب سمعته.

وفي الأسبوع الأول من ال Bootcamp كان المطلوب أن يصل كود المهندس الجديد إلى الإنتاج، ولكن Beck كان حريصاً على كتابة الاختبارات وعمل كل شيء «بالطريقة الصحيحة»، فلم تصل أول ميزة له إلا بعد ثلاثة أسابيع، ويقول إنه تعرض لانتقاد بسبب ذلك وإنه أصيب بما يسمى متلازمة المحتال Imposter Syndrome عندما رأى كم كان كل شيء مختلفاً. ثم تعطلت الاختبارات التي كتبها بسرعة، فحذفت.

وفي المقابل يذكر نتيجتين من ال Bootcamp نفسه:

• أول ميزة أطلقها كانت إضافة الاتحاد المدني Civil Union والشراكة المنزلية Domestic Partnership إلى أنواع العلاقات في الملف الشخصي، ويقول إن قرابة مليون ونصف شخص كانوا يستخدمونها آخر مرة تحقق.
• في مشروع آخر لاحظ أن طريقة جلب البيانات في كود الصور غير فعالة فحسنها، ويقول إنه وفر بذلك «بالصدفة» قرابة خمسة ملايين دولار في السنة.

وهذه أرقام يرويها Beck من ذاكرته، ولم تنشرها Facebook، لذلك نذكرها كما قالها.

كيف عملت Facebook بسرعة مع اختبارات قليلة؟

سأله المذيع في Software Engineering Daily سؤالاً مباشراً: كيف استطاعت Facebook أن تتحرك بهذه السرعة مع عدد قليل من اختبارات الوحدة؟ وإجابته من أهم ما في القصة، وهي من جزأين:

1. نسبة المشاكل التي يمكن اختبارها: كم من مشاكلك يمكن أن تكتشفه قبل الإنتاج، وكم منها لا يظهر إلا في الإنتاج؟ فإذا كتبت حساباً بسيطاً قد لا يتحمل الحجم الحقيقي فلن يكشف ذلك اختبار وحدة، وإذا كانت النسبة تميل إلى أن المشاكل لا تظهر إلا في الإنتاج فإجابة Facebook كما يقول كانت: لا تكتب اختبارات.
2. الاختبارات شكل واحد من التغذية الراجعة Feedback: وكان عند مهندس Facebook أشكال كثيرة غيرها، فكانت كلفة اختبارات الوحدة مقارنة بما تضيفه من معلومات وسرعة وصولها لا تستحق في أغلب التطوير.

والصورة التالية تبين حلقات التغذية الراجعة كما عددها بالترتيب:

ويحكي أن ما صدمه في البداية أن الاختبار الذي يفشل بينما الموقع يعمل كان يحذف، وأن الاختبارات المتقلبة غير الحتمية Non-deterministic كانت تحذف أيضاً، ثم فهم المنطق: هذا الاختبار ينتج ضجيجاً Noise ولا ينتج معلومة Signal، فإذا أزلت الضجيج أصبح الوضع أوضح. وقد شرحنا مشكلة هذه الاختبارات وكيف تتعامل معها في فقرة الاختبارات المتقلبة Flaky Tests.

وعندما علق المذيع بأنك لن تستخدم هذه الطريقة في برنامج محطة نووية، أجاب Beck بالدرس الثاني الذي تعلمه هناك، وهو الفرق بين القرار القابل للتراجع Reversible والقرار غير القابل للتراجع Irreversible، فإذا أطلقت ميزة في نيوزيلندا مثلاً ولم تعجب الناس وأمكنك إطفاؤها بسهولة فهذا قرار قابل للتراجع، ويقول إن هندسة Facebook كانت تبذل جهداً كبيراً لتجعل القرارات قابلة للتراجع حتى لو احتاج ذلك هندسة إضافية. ومن أمثلته:

• عندما تشتري الشركة معدات شبكات جديدة فإن مختبر الفحص لا يهتم كثيراً بأدائها، وإنما يسأل: هل يمكن إطفاؤها بأمان؟ وقال الكلام نفسه في Being Human.
• في مراجعات الكود كان الزملاء يقولون له إن هذا التغيير يجب أن يكون خلف مفتاح Feature Flag، وكان رأيه أن يختبره ثم يطلقه، فتعلم أن هناك أشياء كثيرة لا يمكن اختبارها، وأن البديل عن المفتاح هو إصلاح عاجل Hotfix يغضب فريق هندسة الإصدارات Release Engineering.

وقد شرحنا هذه المفاتيح والنشر التدريجي بالتفصيل في مقال Feature Flags والإطلاق التدريجي.

هل تصلح هذه الطريقة لفريقك؟

لاحظ أن Beck لم يقل إن الاختبارات غير مهمة، وإنما قال إن قيمتها تعتمد على السياق، والجدول التالي يلخص الشروط التي ذكرها في المقابلة مقابل وضع أغلب الفرق:

والخلاصة العملية أنك لا تقم بحذف اختباراتك لأن Facebook فعلت ذلك، والسبب أن الشرط الذي جعل ذلك ممكناً هناك هو وجود كل الحلقات الأخرى وإمكانية التراجع، فإذا لم تكن عندك فإن الاختبارات هي حلقة التغذية الراجعة الأساسية عندك. وقد شرحنا كيف تقيس جودة الكود وأين يعمل كل فحص في مقال جودة الكود Code Quality، وكيف تساعدك أدوات الذكاء الاصطناعي في كتابة الاختبارات في مقال أتمتة الاختبارات بالذكاء الاصطناعي.

من مبرمج بتقييم سيئ إلى مدرب للمهندسين

يقول Beck في Software Engineering Daily إنه قضى قرابة سنته الأولى يعمل على الخصوصية Privacy وعلى الجزء الخلفي من الرسائل Messaging Back-end، واكتشف أنه «probably the worst C++ programmer at Facebook»، أي ربما أسوأ مبرمج C++ في الشركة، وحصل على تقييم سيئ، فعرف أن كتابة الكود ليست ميزته هناك.

ولكن يجدر الانتباه إلى أنه روى في مقال في نشرته سنة 2026 قصة مختلفة عن أول مراجعة أداء له مع مديره David Recordon: كان عنده ستة أهداف لأول ستة أشهر وأنجز ثلاثة فقط، فدخل خائفاً لأن Facebook في تلك المرحلة كانت كما يقول قليلة الصبر على ضعيفي الأداء، فحصل على تقييم «exceeds expectations» لأن العمل الذي شغله عن أهدافه كان مؤثراً. والقصتان لا تتعارضان بالضرورة، فالأولى عن السنة الأولى والثانية عن أول ستة أشهر، ولكنه لم يذكر في أي مصدر وجدناه متى كان التقييم السيئ بالضبط.

وفي المقال نفسه يشرح سياسة كانت متبعة يسميها أهداف P50، أي أن المطلوب أن تنجز قرابة نصف أهدافك فقط، والسبب أن إنجاز كل الأهداف في بيئة استكشاف يعني أحد أمرين: إما أنك لم تتعلم شيئاً، أو أنك وضعت أهدافاً سهلة عن قصد.

بعد ذلك بدأ Beck يعمل مدرباً، ويقول إنه لم يكن في Facebook مدربون، وإنه رأى مهندسين عندهم قدرات كبيرة لم تظهر بعد، والشركة كانت تحل مشاكل غير مسبوقة فلا يمكنها أن توظف من يحلها، بل يجب أن تبني الخبرة من الداخل. فأنشأ برنامجاً سماه Good to Great يعمل فيه مع المهندسين واحداً واحداً، ويقول إنه درب بنفسه قرابة 150 إلى 200 مهندس، وإن البرنامج كان يربط مهندسين كباراً آخرين بمهندسين مبتدئين، وإن من دربهم كانوا أكثر احتمالاً للترقية بمرتين في السنة التالية مقارنة بزملائهم. وهذا رقم يذكره Beck ولم تنشر Facebook بياناته.

وهذا العمل أعطاه شيئاً لم يكن ليحصل عليه كمبرمج في فريق واحد، وهو أنه رأى الكود والمنظمة كلها: فرق تبني أشياء جديدة، وفرق تحسن أنظمة قديمة، وفرق بنية تحتية Infrastructure. ومن هنا جاء أهم ما خرج به من Facebook.

نموذج 3X: الفوضى التي لم تكن فوضى

يقول Beck في Being Human: «when I arrived, it just looked like chaos»، أي أن الشركة عندما وصل بدت فوضى، ثم احتاج خمس سنوات ليفهم أنها ليست فوضى، وإنما ثلاثة أساليب مختلفة تعمل في الوقت نفسه. ونشر الفكرة سنة 2016 في مقال بعنوان The Product Development Triathlon، وفيه يقارن تطوير المنتج بسباق ثلاثي: سباحة ثم دراجة ثم جري، ولكل مرحلة أدوات وتقنيات مختلفة. والصورة التالية تبين المراحل الثلاث:

وتفصيل المراحل كما شرحها:

• الاستكشاف Explore: البحث عن مصدر قيمة جديد لا تعرف مكانه، والاستراتيجية الأفضل هي تقليل كلفة التجربة ووضع استثمار صغير في تجارب كثيرة. ويقول في Software Engineering Daily إن هذه هي المرحلة التي يناسبها شعار «Move fast and break things»، لأنك لا تملك شيئاً تخسره.
• التوسع Expand: تجربة نجحت فجأة، ومثاله البث المباشر Facebook Live الذي انطلق بسرعة الصاروخ فظهرت مشاكل في التأخير ونسبة الاتصالات الناجحة. وهنا تتغير القواعد: تركيز شديد، وغرف عمليات War Rooms، وهي المرحلة الوحيدة التي يرى أن الساعات الإضافية تفيد فيها، وصرف المال على المشكلة منطقي لأن الخطر الأكبر هو ألا تتوسع.
• الحصاد Extract: النمو أصبح متوقعاً والحجم ضخم، فيصبح تقليل عدد السيرفرات 10% مشروعاً مربحاً جداً لمبرمج واحد، بينما في التوسع لو نزلت من 20 سيرفراً إلى 18 فلن يهتم أحد. وهنا تصبح مؤشرات الأداء KPI مفيدة لأنك تعرف الروافع.

ومن أجمل أمثلته على الانتقال بين المراحل أن فريقاً يدخل مراجعة مع Mark Zuckerberg فيخرج سعيداً لأنه جرب أشياء جديدة ونجح أحدها، ثم بعد شهر يدخل المراجعة نفسها وقد استمر في التجريب فيخرج محبطاً، والسبب أن المرحلة تغيرت: الميزة تنمو والنمو بدأ يتوقف، فالمطلوب الآن التركيز عليها. ويشبه ذلك بمباراة كرة قدم يصفر فيها الحكم فتخرج كرة بيضاوية ويدخل فريق آخر وتصبح اللعبة رجبي Rugby، فإذا استمررت بقواعد كرة القدم فسوف تسحق.

وقد يتساءل البعض: أليس وجود أربعة أنظمة لتخزين البيانات من نوع Key-Value في الإنتاج في الوقت نفسه هدراً؟ وهذا مثال حقيقي ذكره Beck، والإجابة عنده أن ذلك هو ما سمح بالاستكشاف السريع، فلو انتظرت كل الفرق النظام المعتمد في الشركة لما حدث الاستكشاف ولا التوسع، ثم في مرحلة الحصاد يصبح توحيدها من أربعة إلى ثلاثة ثم إلى واحد مشروعاً مربحاً، فأربعة مهندسين قد يوفرون ألفي سيرفر.

ويجدر الإشارة هنا إلى أن Beck نفسه يحذر من نسخ Facebook، فعندما سئل في نهاية المقابلة ماذا تأخذ الشركات من Facebook كانت إجابته السريعة «nothing»، أي لا شيء، وأن على كل فريق أن يكتشف طريقته، وقال إن Spotify نفسها لم تنسخ نموذج Spotify. وقد ناقشنا هذا الخطأ في مقال Agile وScrum وKanban بلا شعارات.

«I got fired trying to have it»: السياق الكامل

وفي حلقة Being Human سأله Richard Atherton: هل كان هناك شيء ينقص Facebook ويمكن أن تفعله بشكل أفضل؟ فقال إنه عندما دخل كانت الشركة 2000 موظف وعندما خرج كانت قرابة 25 ألفاً، ثم شرح ما يراه قد سار في الاتجاه الخطأ، وهذا ملخص كلامه بالترتيب:

1. ثقافة Facebook مبنية على دورة مراجعة أداء كل ستة أشهر، وفي كل دورة يجب أن تثبت «impact»، أي الأثر الذي أحدثته على الشركة كلها، ويصف الكلمة بأنها «kind of magical word» لها معنى خاص داخل الشركة: هذا هو المقياس الذي أهتم به، وهذا ما فعلته، وهذا هو الأثر الذي أحدثته أنا شخصياً.
2. هذا يجعل الجميع يركزون على الجانب الإيجابي Upside لما يفعلونه، وهو مناسب في الاستكشاف لأنك لا تملك ما تخسره، ومناسب في التوسع لأن الجميع يبحث عن عنق الزجاجة التالي.
3. المشكلة في مرحلة الحصاد، والشركة كما يقول وصلت إليها من حيث عدد المستخدمين، فالآن عندك الكثير لتخسره.
4. مثاله: مهندس يعمل على Messenger في Android ويريد ميزة تزيد عدد الرسائل، فيجرب ويعدل، ويقترب نهاية الستة أشهر و«You need a win, or bad things are gonna happen in your review»، فيجد نسخة من التجربة ترفع الرسائل 0.2% فيطلقها لأنها تحسب له.
5. وماذا لو كانت لها أضرار جانبية Downsides، كأن تسهل الهندسة الاجتماعية Social Engineering لاستخراج معلومات خاصة، أو تجعل التطبيق أكثر ازدحاماً؟ لا يوجد عندك أي حافز لتنظر إليها، ويقول: «No one is ever going to make a good decision that then makes their own review harder».
6. والحل الذي يقترحه أن تنتقل Facebook من التركيز على الأثر Impact إلى التركيز على جودة القرارات Quality of Decisions، ثم يعترف بنفسه بمشكلة هذا الحل: أنه قد يتحول إلى مهارة في تقديم القرار على أنه جيد، بينما الأرقام على الأقل شيء موجود يمكن النظر إليه.

وبعد أن قال إنه على مستوى معين من الحجم يجب أن تكافئ النظر إلى الأضرار كما تكافئ النظر إلى الإيجابيات، سأله المذيع: هل كان هذا نقاشاً حياً داخل Facebook أم هو رأي شخصي؟ فكانت الإجابة:

"Well, I got fired trying to have it, so."

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

كيف وصف خروجه بنفسه؟

ثم سأله المذيع كيف شعر بعد هذا الخروج، فكانت إجابته أقرب إلى المراجعة الذاتية منها إلى الشكوى، وهذه أهم نقاطها:

• قال إن عدم وجود طريقة له ليساهم داخل المنظمة الرسمية «says a lot more about Facebook than it does about me, but it does say some things about me»، أي أن ذلك يقول عن Facebook أكثر مما يقول عنه، ولكنه يقول عنه شيئاً أيضاً.
• وصف نفسه بأنه قد يكون «abrasive»، أي حاداً في كلامه، وبأنه لا يتوقع أحياناً أن كلامه سوف يغضب الناس.
• قال إنه تعلم الأشياء الكبيرة التي كان يمكن أن يتعلمها هناك، وإنه حاول أن يجعل الفرق تعمل معاً بشكل أفضل في نظام حوافزه كلها فردية فوجد أن ذلك غير ممكن، على الأقل بالنسبة له، وإن «the upside of my contributions was exceeded by the downside of my attempting to contribute»، أي أن الضرر من محاولته المساهمة صار أكبر من فائدة مساهماته.
• وختم بأنه يشعر بامتنان شديد للتجربة، وأنه لم يعد عنده شيء كبير يتعلمه هناك ولا عندهم طريقة للاستفادة مما يجيده، ثم قال: «Time to move on».

وبعد سنة تقريباً، في مقابلة Software Engineering Daily، لم يذكر الطرد، ولكنه عاد إلى الفكرة نفسها في آخر المقابلة فقال إن «impact is this magic word at Facebook and if you don't have impact, you're fired»، وإن الإيجابيات أصبحت أصغر والأضرار أكبر، وتوقع أن الشركة لن تستطيع تغيير هذه الثقافة. ولاحظ أن هذه الجملة وصف لثقافة الشركة بشكل عام، وليست وصفاً لما حدث له.

وكان Beck قد كتب عن هذه القضية وهو ما زال داخل الشركة، ففي نوفمبر 2016 نشر مقال Retrospective Performance Reviews وقال فيه إن مراجعة الأداء أداة تخطيط سيئة لأنها تطلب منك توقع ما لا يمكن توقعه، وتنسب كل الأثر إلى فرد واحد، وتقطع الأثر ليناسب ستة أشهر. وفي مارس 2017 نشر مقال Meeting Prevents Exceeding عن أن تحقيق توقعات الآخرين يمنعك من تجاوزها.

ما الذي لا نعرفه؟

والعنوان الذي انتشر في مقالات مثل هذا يوحي بقصة طرد درامية، ولكن كل ما لدينا جملة واحدة قالها رداً على سؤال، ولم يشرح بعدها كيف حدث ذلك ولا متى، ووصف خروجه في الإجابة نفسها بأنه وقت الانتقال بعد أن تعلم ما يمكن أن يتعلمه، ولم تصدر Facebook أي تصريح عن خروجه. لذلك فالدرس في القصة ليس الطرد نفسه، وإنما النقاش الذي حاول فتحه عن مراجعات الأداء.

أما مقال rackandstack فقد نقل كلام الحلقة بشكل قريب من التسجيل مع اختصار، ثم أضاف الكاتب تعليقه بأن Beck كان يحاول فعل الصحيح مهما كانت الكلفة وأن الكلفة هذه المرة كانت وظيفته، وهذا رأي الكاتب وليس كلام Beck. وكذلك ربطه بقضية Cambridge Analytica هو استنتاج الكاتب، فلم يذكرها Beck في الحلقة.

ماذا يتعلم المهندسون والمديرون من القصة؟

مراجعات الأداء المبنية على الأثر Impact

قياس الأثر ليس خطأ في ذاته، وBeck نفسه يقول إنه مناسب في الاستكشاف والتوسع، ولكن له آثار جانبية يجب أن يعرفها كل مدير يطبقه:

• الإيجابيات فقط تحسب: القرار بعدم إطلاق ميزة ضارة لا يظهر في أي مقياس، فلا أحد يتخذه إذا كان سيضر تقييمه.
• الأثر ينسب إلى فرد: فيصعب العمل المشترك بين الفرق، وهذا ما قال Beck إنه حاوله وفشل فيه.
• الدورة القصيرة تقطع العمل: المشروع الذي يحتاج سنة يقسم ليظهر أثره في ستة أشهر.
• البديل له مشكلته: مكافأة جودة القرار قد تكافئ من يجيد العرض والكلام.

والحل الذي اقترحه Beck في 2016 هو أن يعمل الفريق كما يجب ثم يقسم الأثر في نهاية الدورة معاً، ويتحمل المدير مسؤولية رواية قصة كل فرد. وإذا كنت تبني مقاييس لفريقك فاقرأ فقرة المقاييس التي تبدو جيدة Vanity Metrics، وإذا كنت مهندساً تريد أن تعرض رأياً مخالفاً دون أن تحرق العلاقة فقد شرحنا ذلك في مقال مواءمة أصحاب المصلحة Stakeholders، والقصة تبين أن طريقة قول الرأي قد تكون بأهمية الرأي نفسه، وهو ما اعترف به Beck عندما وصف نفسه بالحدة.

ثقافة الاختبار على الحجم الكبير

الدرس هنا ليس «لا تكتب اختبارات»، وإنما أن الاختبار أداة للحصول على تغذية راجعة، فاسأل عن كل اختبار: ما المعلومة التي يعطيني إياها، ومتى، وبأي كلفة؟ وإذا كان يفشل والنظام يعمل فهو ضجيج، وإذا كانت مشاكلك تظهر في الإنتاج فاستثمر في المراقبة والنشر التدريجي ومفاتيح الإيقاف، ولاحظ أن من يطلق التغيير يجب أن يكون مسؤولاً عنه في الإنتاج، وقد شرحنا ذلك في مقال من يتحمل المسؤولية عندما يتعطل الإنتاج.

الاستكشاف أم الحصاد؟

قبل أن تختار طريقة إدارة لأي مشروع، اسأل في أي مرحلة هو، والجدول التالي يلخص الفرق كما شرحه Beck:

والخطأ الذي يتكرر بحسب Beck هو أن الشركة بعد أن تمر بالمنحنى مرة واحدة تبدأ بإدارة كل مشروع وكأنه في مرحلة الحصاد. وإذا كنت مهندساً في فريق يستكشف فإن دورك قريب مما شرحناه في مقال مهندس المنتج Product Engineer، وإذا كنت مديراً يفكر في إضافة أشخاص إلى مشروع في مرحلة التوسع فاقرأ أولاً مقال هل يسلم الفريق الأكبر أسرع؟.

الخلاصة

وصلنا لنهاية القصة، وأهم ما فيها:

• عمل Kent Beck في Facebook من 2011 إلى أوائل 2018، دخل وهي قرابة 2000 موظف وخرج وهي قرابة 25 ألفاً، ولا يوجد تاريخ دقيق منشور للدخول أو الخروج.
• لم يسجل أحد في درسه عن TDD، فقرر أن ينسى ما يعرفه ويتعلم طريقة الشركة، ثم انتقل من مبرمج بتقييم سيئ إلى مدرب لقرابة 150 إلى 200 مهندس.
• فسر نجاح Facebook مع اختبارات قليلة بأن أغلب المشاكل تظهر في الإنتاج، وبوجود حلقات تغذية راجعة أخرى، وبالاستثمار في جعل القرارات قابلة للتراجع.
• احتاج خمس سنوات ليصوغ نموذج 3X: الاستكشاف ثم التوسع ثم الحصاد، ولكل مرحلة قواعد مختلفة.
• عبارة «I got fired trying to have it» قالها مرة واحدة عن محاولته فتح نقاش حول مراجعات الأداء التي تكافئ الأثر الفردي القابل للقياس بدل جودة القرار، ولم يفصل كيف أو متى، ووصف خروجه أيضاً بأنه نهاية ما يمكن أن يتعلمه هناك.

دليلFeature Flags: انشر الكود وفعل الميزة لاحقاًكيف يفصل ال Feature Flag بين نشر الكود وإطلاق الميزة، وكيف تطلقها لجزء من المستخدمين أولاً وتوقفها فوراً إذا تعطلت.دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.دليلما هي جودة الكود Code Quality وكيف تقيسها؟ما الذي يجعل الكود سهل التغيير، وماذا تقيس أدوات الفحص فعلاً، ولماذا يحتاج كود الوكلاء الأذكياء إلى بوابة جودة.دليلاختبارات يكتبها الذكاء الاصطناعي: متى تثق بها؟أين يساعدك الذكاء الاصطناعي في كتابة الاختبارات وأين يخدعك، ولماذا يبقى قرار ما هو الصحيح بيد الإنسان.دليلمهندس المنتج Product Engineer يملك النتيجة لا المهمةماذا تعني هندسة المنتج Product Engineering كما تصفها الشركات التي تعمل بها، وكيف ينتقل المطور من تنفيذ المهام إلى امتلاك نتيجتها.دليلمن يتحمل المسؤولية Accountability عندما يتعطل الإنتاج؟كيف تحدد ملكية الخدمات وتدير الحادثة بأدوار واضحة، ثم تكتب تقرير ما بعد الحادثة دون لوم وبإجراءات تغلق فعلاً.دليلمواءمة أصحاب المصلحة Stakeholders وسياسة المؤسسةكيف تجعل المؤثرين في القرار شركاء في اقتراحك التقني قبل الاجتماع، وتقول لا مع خيارات، وتصعد خلافاً دون أن تخسر زملاءك.دليلهل يسلم الفريق الأكبر أسرع؟ قانون Brooks والذكاء الاصطناعيماذا تقول الدراسات عن حجم فريق البرمجة وسرعة التسليم، ومتى تفيد إضافة الأشخاص، وما الذي يغيره الذكاء الاصطناعي فعلاً.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من المصادر الأولية: النص المنشور لمقابلة Software Engineering Daily، وتفريغنا الآلي لتسجيل حلقة Being Human، ومقالات Kent Beck في نشرته البريدية، مع Business Insider وJavaScript Jabber وBuilt In للتواريخ.
• أكتوبر 2026: تخفيف الإشارات إلى المصادر لصالح القصة والدروس، وحذف توقيتات الدقائق.