"لإجراء التغييرات ، وفهم لماذا يقاومها الناس": جيم هولمز عن اختبار الثقافة

ماذا يمكن للجيش تعليم المختبر؟ ما هما النقيضين في نهج الاختبار؟ كيف نفسر أن الدين الفني أحمر بالسداد؟ ما المشترك بين الأسئلة السابقة؟

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

- سؤال تمهيدي: حدثنا عن نفسك.

- اسمي جيم هولمز ، وأنا مستشار مستقل ومالك لشركتي الخاصة ، أنظمة أنظمة التوجيه. أنا متخصص في جودة توصيل البرامج ، وقد قمت بالبرمجة لما مجموعه حوالي 20 عامًا ، قبل أن أخدم في الجيش لفترة طويلة. أصبحت مهتماً للغاية بالجودة منذ حوالي 15 عامًا ، بينما كنت أعمل على العديد من المشاريع غير الناجحة. بشكل عام ، لقد أجريت الكثير من أتمتة الاختبار ، واختبارات الوحدة ، واختبار التكامل ، وخاصة الاختبار الوظيفي ، واختبار واجهة المستخدم. على وجه الخصوص ، عملت في شركة كتبت أداة Telerik Test Studio الرائعة. وفي السنوات 5-8 الماضية ، بدأت في التعامل ليس فقط مع الجوانب التقنية البحتة ، ولكن أيضًا مع جودة العرض ككل - أي مدى جودة العلاقة بين فريق التوريد والأعمال. ولكن في الوقت نفسه ، ما زلت أراجع أخطاء البرامج النصية WebDriver لفترة طويلة وحل المشكلات مثل الفشل الدوري بسبب الإجراءات غير المتزامنة غير الصحيحة. أنا أعيش في مدينة آشلاند في ولاية أوريغون - فكر فيك ، وليس في بورتلاند (عندما تقول في الولايات المتحدة الأمريكية "أوريغون" ، عادة ما يعتقد الجميع "بورتلاند").

- على الأرجح ، بالنسبة للمختبر ، فإن الجزء الأكثر غرابة من سيرتك الذاتية هو الخدمة العسكرية. ماذا كنت تفعل بالضبط هناك؟

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

بالنسبة لسؤالك ، تجربة الخدمة العسكرية غير عادية ليس فقط للمختبرين ، ولكن أيضًا للعديد من المجالات الأخرى. أستطيع أن أقول إنني على الأقل علمت الانضباط هناك.

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

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

تركت الجيش قبل 25 سنة - نعم ، أنا رجل عجوز - وعمل في القطاع المدني يتناقض بشكل مثير للاهتمام مع تجربتي السابقة بسبب الأولويات هناك. في الجيش ، خدمت على متن طائرة ، كان من المفترض أن أراقب العدو على مساحة كبيرة وأضمن سلامة بلدي. أي خطأ يعني مخاطرة بحياة جنودنا. لا أريد المبالغة ، لكنها كانت كذلك بالفعل. لذلك عندما يبدأ شخص في مجال تكنولوجيا المعلومات بالذعر ويطالب بحل مهمة على الفور ، بفضل انضباطي وتجربتي ، يمكنني دائمًا طمأنة الناس - نحن لسنا مهددين بأن يموت شخص ما ، ولا نفقد مئات الآلاف من الدولارات في الدقيقة (وقد كنت في مثل هذه المواقف). غالبًا ما نشعر بالذعر وندع الأعمال أو المساهمين يرعبوننا بلا داعٍ ويخلقون توترات غير معقولة لا تفيد أي شخص. ربما يكون أفضل شيء علمني إياه الجيش هو القدرة على الدعوة إلى الهدوء ، وتقييم الوضع بشكل سليم ، والتخطيط لأفعالنا مسبقًا ، وعدم التسرع في مهمة دون تفكير بسبب الذعر المصطنع.

- أي أنك تحتاج إلى بعض الوقت للتفكير من خلال استراتيجية.

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

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

- هذا سؤال رائع. بالإضافة إلى عملي المستقل ، أعمل أيضًا مع Pillar Technology من كولومبوس ، أوهايو. لقد عرفت أشخاصًا من هذه الشركة منذ فترة طويلة. يعمل الآن حوالي 250 شخصًا ، ويعمل جميعهم تقريبًا على مبدأ البرمجة المتطرفة (XP): لديهم الكثير من اختبارات الوحدة ، ويتم التفكير في التطوير جيدًا. عندما تم تعييني هناك قبل ثلاث سنوات ، كنت المختبر الوحيد ، وقاموا بإنشاء منتج عالي الجودة. لقد اقتربوا من الاختبار حصريًا من موقع XP ، من موقع التطوير القائم على الاختبار. يعد هذا نهجًا رائعًا ، وقد قاموا بتطبيقه بنجاح ، وتمكنت مع بعض الموظفين الآخرين من تغيير بعض جوانب تسليم البرامج.

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

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

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

- وفي ممارستك للاستشارة ، هناك أوقات عندما قالوا لك بعد الانتهاء من العمل مع الشركة "لم يتحسن شيء"؟

- سأخبرك بسر أنه صعب مع الناس ، نحن مخلوقات صعبة للغاية. هذا أحد الأسباب التي تجعلني أشعر بالكثير من الشعر الرمادي (والثاني هو ابنتي). تغيير شخص واحد أمر صعب ؛ تغيير الأشخاص في مؤسسة أكثر صعوبة. لذا نعم ، لدي هذا الموقف في كثير من الأحيان.

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

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

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

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

- تقوم بعقد ندوات ، وفي أحدها يعلم برمجة الناس الذين لا يعرفون كيفية البرمجة. لدي سؤالان. أولاً ، ما هي المشاكل التي تمنع الأشخاص في الغالب من البرمجة الذاتية؟ ثانيًا - هل تعتقد أنه خلال العام المقبل سيسود الاختبار الآلي على الاختبار اليدوي؟

- في تجربتي ، غالبًا ما ينزعج الناس من الصعوبات التقنية ، ولكن بسبب الخوف. يمكنني تقديم مثال من تجربتي في شركة من Fortune 10 ، والتي تحدثت عنها بالفعل. لقد عملت مع فريق من المختبرين الذين أجروا الاختبار اليدوي ، وكان علينا إجراء أتمتة باستخدام WebDriver. من بين هؤلاء ، لم يتمكن معظمهم من فتح Eclipse لبدء كتابة التعليمات البرمجية. كانوا خائفين من كتابة نص برمجي للأتمتة ، لأن فهمهم لم يكن مختلفًا كثيرًا عن كتابة خدمة ويب قابلة للتطوير أو قاعدة بيانات تحتوي على مؤشرات متعددة ، أي الأشياء التي تعلمها المطورون لسنوات. هذا الخوف منعهم من القيام بأشياء بسيطة بشكل عام.

أقوم حاليًا بإعداد دورة تدريبية لوزارة الاختبار استنادًا إلى ورشة عمل أشرح فيها أنك لا تحتاج إلى سنوات من الممارسة لفتح ملف Java أو C # أو نص روبي ببساطة أو قراءته وفهم الهيكل العام أو الكتابة اختبار بسيط على WebDriver. علاوة على ذلك ، حتى إذا كنت لا تفهم تمامًا كل ما يحدث في الشفرة ، يمكنك إجراء تقييم عام لها ، لأنك تعلم ، على سبيل المثال ، أن إحدى الطرق لا يجب أن تشغل ثلاث شاشات ، يجب ألا يكون هناك أربعة متداخلة إذا كانت العبارات - ستكون صعبة للاختبار ، لا يمكنك إعطاء أسماء من حرف واحد للمتغيرات وما إلى ذلك. في رأيي ، في المرحلة الأولية ، تتمثل الصعوبة الرئيسية في التغلب على الخوف من أنه سيكون عليك حل المهام المعقدة بشكل لا يصدق. وكنت دائمًا مهتمًا برؤية مدى سرعة تخلص موكلي من هذا الخوف - ما عليك سوى إجراء اختبار بسيط على الشخص واطلب منه كتابة الترتيب والتصرف والتأكيد. أعتقد أن هذا العنصر البشري مهم للغاية.

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

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

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

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

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

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

, . , , , , — , . , .

, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .

— . «The leadership journey» . , : , , — . ?

— , , IT: , , , , . , , , , . , , , . , , .

, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .

— , . : , , , . — ?

— 18 , , 13 14. . , — , , . , , . , .

, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .

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

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

— «Technical debt: payment plan». « » , « » , . , , , , ?

- هذه قضية مهمة جدا. أعتقد أن أي شخص يعمل في مجال تكنولوجيا المعلومات لأي فترة زمنية يجب أن يكون قد واجه مشكلة الديون التقنية. هنا أريد أن أشكر Trish Khoo ، على Twitter يمكن العثور عليه على أنه hogfish. إنها مختبرة ممتازة ، لقد عرفتها منذ سنوات عديدة. في الواقع ، كتبت ما بعد "الديون الفنية: خطة السداد". أردت أيضًا أن أكتب عن هذا عندما قرأت هذا المنشور ، لأنني لخمس سنوات ألقيت خطابات في المؤتمرات ، حيث عبرت بشكل عام عن أفكار مماثلة.

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

, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .

, , . , , . , , , . , .

— , , , . , , , .

— . , . , , , . , , — , . , , - . .

, . , , , , . , , , , , , . , , , .

— , — . , .

— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.

, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .

— . .

— , . , : , .