آمل أن أكون قد تمكنت من لفت انتباهكم بهذا العنوان الاستفزازي (والمبالغ فيه). جيد. دعني الآن أعيد صياغتها بطريقة أكثر أناقة وأقل
جاذبية :
من حيث المبدأ ، يمكن كتابة البرنامج إما في الوقت المحدد أو بشكل جيد ، ولكن ليس كلاهما في نفس الوقت ** باستثناء حالات قليلة في الفرق الحالية عالية الأداءلقد كنت أفكر منذ عدة أشهر في سبب عدم ملاءمة إنشاء برامج عالية الجودة مع التواريخ والتخطيط التقديري بشكل عام. خلال مسيرتي ، رأيت مشاريع مبنية على مجموعة متنوعة من النماذج (متتالية ومرنة
حقًا ومرنة ومتتالية) ، وكان لديهم جميعًا شيء واحد مشترك: بغض النظر عن المشروع الذي نعمل عليه إذا تم تنفيذه "
في مجال العلوم" ( أي أننا لم نسمح لأنفسنا بالحيل القذرة ، والتي بسببها سيكون لدينا في وقت لاحق كوابيس) ، ثم كنا دائمًا نخالف المواعيد النهائية.
من ناحية أخرى ، كلما تم تسليم المشروع "في الوقت المحدد" ، كان هذا يعني أنه على طول الطريق كان لا بد من تقليل حجمه ، أو قطع الكثير من الزوايا التي تراكمت خلال جبال التنفيذ من الديون التقنية ، مما يضمن تقريبًا إعادة كتابة المشروع بعد فترة وجيزة إطلاق. لذلك ، بدأت أتساءل: هل يمكننا أن نفترض حقًا أن المشروع قد تم تسليمه "في الوقت المحدد" إذا كان لدينا نتيجة قبيحة وغير ملائمة للدعم ، محشوة بالأخطاء ، وبصراحة ، نسخة
أكثر قبيحة من الشفرة مقارنة بما كنا أصلاً حاول أن تفعل؟
ترجم إلى Alconostلقد أتيحت لي الفرصة للعمل في مشاريع بدون مواعيد نهائية صارمة. نعم ، كانت هناك "مواعيد نهائية" رسمية ، لكنها بعيدة كل البعد عن الخرسانة المسلحة. فهم الجميع أن المواعيد النهائية لدينا مرنة ، وأن الجودة أكثر أهمية من تسليم المنتج في الوقت المناسب. في هذه المشاريع ، حصلنا على أفضل البرامج ، وكان هناك أكثر المطورين رضاءً ، وبشكل عام ، كانت هذه المشاريع من بين المشاريع الأكثر نجاحًا بين كل ما كان علي العمل عليه. لكننا نعلم جميعًا أن مثل هذه المشاريع نادرة جدًا ، وإلا لما كنت قد كتبت كل هذا.
لذا ، لماذا من الصعب جدًا التخطيط للعمل وإعطاء برامج جيدة ، مع تحديد مواعيد نهائية صعبة؟ أعتقد أن هذا يرجع إلى حد كبير إلى
الإبداع والمهارة وعدم
القدرة على التنبؤ .
الجانب الإبداعي من البرمجة
أنا أرى أن
تطوير البرمجيات ، بحكم تعريفه ، نشاط إبداعي . بالطبع ، هناك مطورون يؤدون نفس المهام التافهة ، ولكن لديهم عمل فقط حتى يكتشف شخص ما كيفية أتمتة عملهم. لن تحسدهم ، وموضوع هذه المقالة مختلف تمامًا.
بالنسبة لي ، هناك شيء خاص في عملية
إنشاء شيء جديد وفي البحث عن حلول أصلية استجابة للتحديات ؛ لهذا السبب أشعر أنني مدعو لتطوير البرمجيات ، ولا أعتقد أنني الوحيد. في الواقع ، أعتقد أن الإبداع هو السبب الرئيسي وراء استمتاع المطورين بعملهم. تقترح تجربتي أنه كلما عملت في ظروف لوحظت فيها "مجموعة من الممارسات" الصارمة وغير المتغيرة (سواء كانت مكدسة تكنولوجية ، أو عمليات ، أو تنظيمًا ، وما إلى ذلك) ، فسيكون هناك مساحة أقل للإبداع كنت - كلما كنت مفتونًا بهذا العمل. "في النهاية ، إذا كانوا قد قرروا بالفعل كل شيء لأنفسهم ، فلماذا يحتاجون إلي؟" - اعتقدت. من ناحية أخرى ، كنت أكثر شغلًا ، مستوحاة من هذا العمل (الذي كنت فيه الأكثر إنتاجية أيضًا) ، حيث كانت هناك توجيهات قليلة نسبيًا من الأعلى ، وكان هناك مجال للإبداع ، وكان لدي ثقة في اتخاذ القرارات الفنية بنفسي.
من المهم أن نلاحظ أن الحرية الإبداعية الإضافية تؤدي إلى حقيقة أنه في طريق التوصل إلى حل سيكون هناك حتمًا المزيد من التجربة والخطأ - وهذا أمر طبيعي. يبدو للبعض أنه يمكنك ببساطة معرفة الحل المثالي بشكل
مسبق (مقدمًا) دون كتابة سطر واحد من التعليمات البرمجية. على العكس من ذلك ، أصر على أنه في العملية الإبداعية ، يتطلب المسار لاكتشاف حل لمهمة (وهذا لا ينطبق فقط على البرامج)
العبث : من المستحيل معرفة كل شيء مقدمًا بالتأكيد ؛ على العكس من ذلك ، تتعلم في الممارسة ، والفرز التدريجي من خلال الخيارات الجديدة والالتزام بالخيارات التي تعمل ، وصقل قرارك (وربما تسليمه تدريجيًا للعملاء إذا كنت تعمل وفقًا لمنهجية "مرنة") حتى تكون سعيدًا بها.
فقط فكر في عدد المرات التي استغرقها التصميم الدقيق للعنصر على الورق - عندها فقط ، لإعادة التصميم بالكامل ، كان الأمر يستحق البدء في التنفيذ فقط. سيكون هناك دائمًا
مجهول غير معروف في هذا النشاط التجاري
، ويمكنك التعرف عليهم والتعامل معهم فقط في
الخلفية (في الواقع) ، وبرمجة الحل الخاص بك ، وعدم قضاء الكثير من الوقت في التنظير وعدم التظاهر بأنه يمكننا امتلاك معلومات مثالية مقدمًا. هذا الارتجال لا يتناسب بشكل جيد مع التواريخ المقدرة.
بالإضافة إلى ذلك ، كما هو الحال مع الأنشطة الإبداعية الأخرى ، من المفيد ممارسة
التسويف الاستراتيجي عند البرمجة - تم اقتراح هذا المصطلح لأول مرة من قبل آدم غرانت ، الذي يدعي أنه غالبًا ما يفشل في الإنشاء
عند الطلب ، ولكن ، على العكس من ذلك ، يأتي الإبداع على أنه "إشعار دفع
" من عملية تجري في الخلفية في رأسك:
"عادة ما يكرس الموظفون المماطلون المنتظمون مزيدًا من الوقت للتفكير المتباعد ، وكثيرًا ما يصنفهم القيمون على أنهم أكثر إبداعًا من الزملاء. لا يؤجل التسويف دائمًا الإبداع: إذا لم يكن لدى الموظف دافعًا واثقًا لحل مشكلة كبيرة ، فبسبب انزلاقها ببساطة يتخلف عن الركب. ومع ذلك ، إذا كان الشخص متحمسًا بما فيه الكفاية بشأن العمل وقدم أفكارًا جديدة ، ثم تأجيل المهمة ، فهو يأتي إلى حلول أكثر إبداعًا ".
- جرانت ، آدم. "الأصول: كيف يحرك غير المتوافقين مع العالم"
مرة أخرى ، لن يرضي هذا دعاة
التخطيط المركزي الذين يسعون إلى توقع وقياس كل دقيقة في مشاريع تطوير البرمجيات.
درب التبانة والمريخ والنيزكمهارة البرمجة
أفضل المطورين الذين أعرفهم هم حرفيون مهرة. الإتقان ميزة مميزة للبرمجيات الجيدة:
أنت تنشئ شيئًا يعمل ، وتنشئه بأفضل طريقة ممكنة - من السهل نسبيًا إنشاء شيء يعمل ، ولكن من الصعب جدًا القيام بشيء لن يعمل فقط ، بل سيصمد أيضًا أمام اختبار الزمن.
نظرًا لأنك سيد ، فإن جودة عملك تتحدث عنك . بالنسبة لك ، الجودة هي أكثر أهمية من الكمية ، لأنك لا تريد أن يتم الاعتراف بك كمؤلف govnokod ، حتى إذا كان بإمكانك إرضاء مدير المنتج من خلال منح برنامجك لمعانًا خارجيًا ، وداخله مع مجموعة من المفاجآت الخسيسة - أسمي هذا النهج
Kindersurprise Development . أنت تعلم أن تكريس وقت كافٍ لحالة ما وكتابة برنامج جيد هو أمر صحيح ، لذا قاوم الضغط "افعل ذلك بشكل أسرع" ، لأنك تعلم أنه كلما زاد عدد العكازات التي قمت بإعدادها الآن ، كلما كانت التعليمات البرمجية أقصر ، والمزيد من المشاكل ستكون معها الأعمال.
نزيف العيونتهتم الصناعة اليدوية
بالرعاية : نحن نهتم بعمل عمل ممتاز ، وبشأن أولئك الذين سيتعين عليهم الحفاظ على رمزنا بعدنا ، حول عملائنا الذين يجب أن يكونوا سهل الاستخدام مع برنامجنا ، حول زملائنا في الفريق ، إلخ. أنت تفعل ذلك لأنك لست أحمقًا ولأنك تعرف أن هذا ما يجب عليك فعله إذا كنت تهتم بنجاح المشروع.
باختصار ، لدى المهندس الجيد مهمة صعبة: العناية بالجودة - التي سيتم الشعور بها على المدى الطويل - في عالم يتم فيه تحديد كل شيء بسرعة.
من الناحية العملية ، يتم التعبير عن هذا في أشياء مماثلة:
- ابحث عن التركيبة الصحيحة بين التغليف والتوسعة وقابلية التوسع وما إلى ذلك. - مرة أخرى ، ستكون هناك حاجة إلى نهج تكراري عن طريق التجربة والخطأ ، لأنه لا أحد ينجح في بناء أفضل حل في المحاولة الأولى.
- خصص وقتًا لإعادة البيع إذا صادفت رمزًا سيئًا بشكل مخجل.
- قم بكتابة اختبارات جيدة وكاملة - حتى قم بإجراء TDD
- البرنامج بالترادف مع زميل
وغني عن القول أنه من المستحيل التخطيط لكل هذا مسبقًا ، لذا فإن اتباع نهج مماثل لن يساعدك على الوفاء بالمواعيد النهائية.
توقعاتك خاطئة
"حتى إذا كانت هناك متطلبات واضحة - ويبدو أنه لم يحدث أبدًا ، فمن المستحيل تقريبًا حساب المدة التي تستغرقها وظيفة معينة ، حيث أننا لم نحل هذه المشكلة من قبل. إذا قررت ، فما عليك سوى أن تعطيك النتيجة ".
- رون جيفريز ، حركة NoEstimates
مشاريع البرامج هي
أنظمة معقدة : يتم إنشاؤها من قبل الناس ، وبالتالي تتحمل بصمة العلاقات الشخصية ، والتحفيز ، ومشاكل الاتصال وعلم النفس البشري بشكل عام - كل هذا صعب للغاية لتصميمه وتحديده في الجدول إذا كنت مهتمًا برأيي. لذا ، من الصعب جدًا تصميم مشاريع البرامج (وبالتالي التنبؤ). من الأفضل تفسير نسيم طالب في كتابه "
مكافحة الهشاشة" :
"الأنظمة المعقدة شديدة الترابط (التي يصعب التعرف عليها) وردود الفعل غير الخطية. تعني كلمة "غير خطية" أنه عندما تضاعف ، على سبيل المثال ، جرعة الدواء أو عدد العاملين في المصنع ، فإن العائد لن يكون ضعف ذلك ، ولكن إما أكثر أو أقل بكثير. هذا لا يعني أن عطلتي نهاية الأسبوع في فيلادلفيا أكثر متعة مرتين من واحدة - يمكنني أن أقول هذا من تجربتي الخاصة ... "
- نسيم نيكولاس طالب ، مكافحة الهشاشة
الأسوأ من ذلك ، بالنظر إلى أن الوقت لا يمكن أن يكون قيمة سلبية ، فمن المحتمل أن تؤدي أي "مفاجآت" غير مخطط لها إلى تأخير إكمال المشروع ، بدلاً من تقريبه ، لأن هناك
عدم تماثل في النتائج:
"الوقت ليس قيمة سالبة ، مما يعني أنه لا يمكن تنفيذ مشروع لمدة ثلاثة أشهر في فترة زمنية صفرية أو سلبية. لذلك ، على المحور الزمني ، الذي ينتقل من اليسار إلى اليمين ، تتراكم الأخطاء على اليمين ، وليس على اليسار. إذا كان عدم اليقين خطيًا ، فسنرى أن بعض المشاريع يتم إنجازها بشكل كبير قبل الموعد المحدد (حيث نصل أحيانًا إلى مكان قبل ذلك بكثير ، وأحيانًا بعد ذلك بكثير). لكن في الواقع ، الأمر ليس كذلك ".
- نسيم نيكولاس طالب ، مكافحة الهشاشة
هذه أخبار سيئة ، لأن
عدم اليقين مضمون ، وحتى الأخطاء الصغيرة في تقييم المهام الفردية ستتراكم بشكل كبير على نطاق المشروع. علاوة على ذلك ، نعتبر هنا أفضل حالة عندما يتم تحديد المواعيد النهائية من قبل المطورين أنفسهم بعد تقييم دقيق للتوقيت. ومع ذلك ، فإن الواقع أكثر سخافة بكثير: في معظم الحالات ، يحدد "العمل" المواعيد النهائية كما يشاء ، وعندها فقط يأتي المهندسون إلى العمل ، ويخططون كيفية تلبية جميع المتطلبات لهذه الفترة المحددة بشكل تعسفي ؛ القضية فظيعة مثل بدء منزل من السطح ، وليس من الأساس ، أو وضع عربة أمام الحصان.
سؤال جيدفيما يلي بعض الأمثلة التي توضح عدم خطية تطوير البرامج وحلقات الملاحظات الناتجة:
- لقد اقترحت ذات مرة أن واجهة برمجة التطبيقات التي تريد
accountId تقبل accountId ، ولكنها في الواقع تقبل memberId فقط. أضف إلى الفترة المقدرة 4 أيام التي تحتاجها لإعادة صياغة رمز API - وبعد ذلك ، ستحتاج إلى مراجعة منفصلة ، والتي سنضيف لها يومين آخرين.
- تستمر المهمة التي كنا نأمل في حلها في يومين لمدة أسبوع ، لأنه في عملية المراجعة ، يفرض عليك أحد الزملاء (ويفعل ذلك بشكل صحيح) إعادة صياغة وتحسين الجزء المثير للشفرة من التعليمات البرمجية الذي كان ينتظر منذ فترة طويلة في الأجنحة.
- تذكر هذه المهمة لمرة واحدة عندما كنت بحاجة إلى تنفيذ فرصة جديدة واحدة فقط. ولكن اتضح أنه لهذا تحتاج إلى تحديث التبعية ، التي استغرقت 4 أيام ، وأثارت هذه العملية رد فعل متسلسل مع تحديث التبعيات الأخرى ومجموعة كاملة من التبعيات أثناء التجميع.
هل أخطأنا؟
نحن ببساطة عن طريق القصور الذاتي نواصل لعب هذه اللعبة بالتقييمات والتخطيط ، فقط لنطمئن أنفسنا: من المفترض أننا مسيطرون على الموقف. لكن في الواقع ، نحن لا نتحكم في أي شيء. تظهر التجربة أن مشاريع البرامج غير متوقعة. لذا أعتقد أنه من الأفضل التركيز على
الأعمال بدلاً من التخطيط -
# لا تقديرات ، من معي؟ ومع ذلك ، بالطبع ، لن ينجح هذا في العديد من المؤسسات: "لا يمكنك فقط أن تأخذها وتترك المهندسين يديرون الكرة حتى لا يتحكم بها أحد. يجب أن تكون هناك مساءلة! " فهمت.
لا تقول ذلك؟ثم ماذا تفعل؟ أعتقد أن هذا يتلخص في تضييق الفجوة بين عالم الطاولات وعالم IDE من أجل تزويد المهندسين بأقصى قدر من الإبداع والمرونة وحرية إظهار الإتقان ، ومع ذلك ، في نفس الوقت ، الالتزام بشكل مسؤول بالوعد وتلبية توقعات أصحاب المصلحة في المشروع. المدير الفني (مدير الهندسة) - أفضل متخصص في بناء مثل هذه الجسور ، والذي يمكنه أيضًا استيعاب الفجوة بين العالمين. هذا العمل ليس سهلا ولكنه ضروري. إليك مدى حديث آرون لونجويل عنها في مقالها:
"بما أن المديرين الفنيين يعيشون على الحدود بين الأعمال والتقنيين ، فإنهم هم الذين يتعين عليهم حل التناقضات بين التوقعات والواقع. إنها مثل تعليق رافعة ، يتم سحبه في اتجاهات مختلفة: يمكن أن ينجذب على كلا الجانبين. إذا فازت الأعمال ، يتم دفع المطورين حتى الموت. إذا كانت الاعتبارات الهندسية تفوق تلك المتعلقة بالأعمال ، وداعًا للميزانية والمواعيد النهائية. في أي حال ، فشل. يجد مدير مشروع برنامج ناجح طرقًا للعمل بمرونة ؛ لتنتج ، لا تكسر ، وتحل الاحتكاك تدريجياً. يمكن للقيادة كنهج الخدمة أن تساعدك على أن تصبح أكثر مرونة ".
- آرون لونجويل ، لماذا يتطلب تطوير البرمجيات قادة خادمين
من المهم أيضًا إنشاء علاقة ثقة قوية بين الإنتاج والمهندسين. إذا كانت هناك ثقة ، فعندئذ يمكنك التفاوض بصدق وضمير بشأن المواعيد النهائية. إذا كنت قد أثبتت بالفعل أن فريقك يصنع برامج جيدة ، فيجب أن تتمتع بسمعة جيدة إلى حد ما ، وينبغي أن يثق بك أصحاب المصلحة ، مع العلم أنه إذا كنت خارج الجدول الزمني ، فعندئذ لأسباب وجيهة ومن أجل الصالح العام.
"خدعة" أخرى استخدمتها شخصيا كمدير ليست تسمية تواريخ محددة ، لأنها تتحول حتما إلى مواعيد نهائية صعبة. من الأفضل إعطاء تواريخ غامضة ، على سبيل المثال ، "ثلاثة إلى خمسة أسابيع". في هذه الحالة ، عند الاقتراب من هذا الموعد النهائي الهش ، تضيف: "في أبريل أو مايو" ، والذي يمكن تفسيره بسهولة على أنه "بين 15 أبريل و 3 مايو" في أوائل أبريل ، حوالي 10 أبريل ، يمكن أن يتحول إلى "بحلول 20 أبريل "، إلخ. في هذه الحالة ، لا تفكك ، وتتواصل مع الزملاء ، ويوفر الفريق مرونة الشروط المطلوبة لحل المشاكل غير المتوقعة التي لا مفر منها التي تنشأ.
أخيرًا ، تذكر أن المطور هو المسؤول عن الجودة الفنية للمنتج المصدر ، وليس الأطراف المعنية الأخرى. من الطبيعي أن يكون هناك احتكاك بين المنظمات ، والتي ، للوهلة الأولى ، تسترشد بحوافز مختلفة. في هذه الحالة ، من المهم أن نلاحظ أن جميعكم (من المفترض) متحدون بهدف مشترك: إعطاء العميل برامج عالية الجودة في أقصر وقت ممكن. من الواضح أن المطورين الجيدين فقط هم القادرون على التفكير بهذه الروح وفهم أنه من المهم تجنب نهج "واحد ، اثنان - وفعل!" المخادع ، وهو أبطأ على المدى الطويل.
في الختام ، سأقول أن هذه مشكلة قابلة للحل ، وإن كانت معقدة (وشائعة). أود أن أقول أنه إذا لم يكن مديرك أو مؤسستك ، في رأيك ، يميل إلى كتابة برامج جيدة ، فأنت بحاجة إلى التحدث عنها ومحاولة تغييرها ؛ إذا فشل هذا ، ابحث عن وظيفة أخرى.
عن المترجمتمت ترجمة المقال بواسطة Alconost.
تقوم Alconost بتوطين
الألعاب والتطبيقات والمواقع بـ 70 لغة. مترجمون لغتهم الأم ، اختبار لغوي ، منصة سحابية بواجهة برمجة تطبيقات ، تعريب مستمر ، مدراء مشاريع 24/7 ، أي تنسيق لموارد السلسلة.
ننشئ أيضًا
مقاطع فيديو إعلانية وتدريبية - للمواقع التي تبيع ، والصور ، والإعلانات ، والتدريب ، والتشويش ، والشرح ، والمقطورات لـ Google Play و App Store.
مزيد من التفاصيل