التطوير ... يشبه المخدرات - يكتبون نظامًا ، يكتبونه ، لأنه يهرع. ثم اتضح فجأة - يجب دفع "النفقة". وأي تغيير في النظام يؤدي إلى جبل من الأخطاء. لكن حتى في بداية القرن الماضي ، توقع
كورت جودل العظيم هذا
وأثبت بصرامة أننا حتى في الحساب ، نفتقر إلى الذكاء للتعبير عن جميع قوانينه دون تناقضات. وفي البرمجة وحتى أكثر من ذلك - سنبدأ في الوقوف على أقدامنا ونشوش. وهذا ما يحدث بشكل عام: إما أن يكون الكمبيوتر المحمول قيد التشغيل ويعيد تشغيله في الليل ، ثم ترتكب تطبيقات الهاتف المحمول الأخطاء حتى يبدأوا في التساقط من الجيب والتشتت والتلويح والصرير على الأرض.
وكيف تحب إصدارات بيتا العصرية من كل شيء وكل شيء الآن؟ قريبا ستبدأ الطائرات في الظهور في إصدارات ألفا بيتا ، على ما يبدو.
ولكن يمكنك البرنامج دون أخطاء حتى تفرح الروح وليس من الجيد فقط شرب البيرة مع العميل ، ولكن أيضًا آمن!
في هذه السلسلة من المنشورات حول مختلف جوانب تطوير البرمجيات ، سأحاول إنشاء مجموعة بسيطة من القيم والقواعد ، أولاً ، يتم وضعها في رأس الشخص العادي ، وثانياً ، تسمح عادة ... للفوز بأقل تكلفة ووقت. اليوم ، دعنا نتحدث بصراحة عن جمع المتطلبات لنظام البرمجيات.
مسرح ، مسرح في كل مكان. لكن صناعة تطوير البرمجيات سوف تستفيد بلا شك إذا أخبر جميع المشاركين في العملية الحقيقة ، أولاً ، لأنفسهم ، وثانياً ، لن يدعم أي شخص العواطف غير النظامية والوزارة لتثولهو حولها.
لا تحتاج إلى الذهاب بعيدًا للحصول على أمثلة - نماذج التنمية المفتوحة ونجاحها (وليس بالضرورة غير هادفة للربح) تظهر بشكل مقنع:
- الوضوح والانفتاح والشجاعة
- مناقشة مع المجتمع والعميل
- تحديد المشكلة بسرعة وحلها
بالإضافة إلى الاتصالات الأكثر إنصافًا القائمة على الثقة والاحترام المتبادلين - قيادة حل البرمجيات ، على سبيل المثال ، موقع ويب ، لتحقيق النجاح.
العالم يتغير بنشاط. تحدث الاتصالات الأفقية بسرعة الضوء ، وإذا لم نتعلم كيفية استخدام هذا السلاح الجديد ، فسنخسر بالتأكيد. لكن أولاً ، ألقِ نظرة حولك.
من أين جاءت "الحروب المقدسة" في البرمجة؟
كل شيء بسيط. يكفي أن نتذكر مسار الهندسة المدرسية. يعتمد الفهم العلمي للعالم الذي نعيش فيه على ... الإيمان بـ "الحقائق الثابتة" = البديهيات ، على سبيل المثال ، أن "الخطوط المتوازية لا تتقاطع" أو في عدد الأعداد الأولية
في نطاق (على الرغم من أن هذه نظرية ، لكنها الكلب يعمل ، ولكن لا أحد يفهم لماذا).
من المستحيل إثبات البديهية ، يبقى فقط الاعتقاد بأنها تعمل دائمًا. لكن لا يمكننا الطيران إلى أفق حدث Black Hole والتحقق منه. واشرح لماذا ينتقل التفاعل بين الفوتونات أسرع بكثير من سرعة الضوء
أيضًا .
تستخدم العديد من النظريات العلمية البديهيات من أجل الاستنتاج المنطقي للنظريات ، وما إلى ذلك ، لذلك يتم إنشاء كتب سميكة مع فترة ضمان معينة. كنتيجة لذلك ، وهذا لم يعد مضحكا ، لقد
أثبتت نظرية فيرما العظيمة
في التسعينيات بطريقة أن حفنة من أولئك الذين لديهم مستوى ممتاز من التعليم الخاص يمكنهم فهم البرهان ، وقادرون على تجريف عشرات الصفحات من نص جيد مع صيغ تحت المجهر :-) البحث عن أدلة "حقيقية" ، بسيطة وجميلة.
حتى في ما يبدو أنه يمكن أن يكون أكثر بساطة ، حسابي ، بذلت محاولات متكررة لترتيب البديهيات - لكن الأمور ما زالت قائمة ...
وبالمثل ، فإن لغات وتقنيات البرمجة التي ننشئ عليها مواقع الويب والتطبيقات المحمولة وأنظمة المعلومات ، في الواقع ، تمثل أيضًا مجموعة من البديهيات أو النقاط المرجعية ، التي تحتاج أيضًا إلى "الإيمان بها" والتي تم بناء أساس التكنولوجيا عليها ، لكن من المستحيل إثبات أنها صحيحة (على الرغم من أنه في بعض الأحيان لا يزال ممكناً: حاول كتابة موقع على شبكة الإنترنت في C ++ ومعرفة مقدار الوقت والمال الذي تخسره).
على سبيل المثال ، في عالم Java / C # ولغات أخرى موثوقة وذات سمعة جيدة وحديثة ومكتوبة بالكتابة الساكنة ، ما عليك سوى أن تأخذ وتعتقد أن العالم يتكون من مختل عقليا ، عرضة للعنف وفقدان الهوية الذاتية ، وبالتالي "مجموعة من البديهيات" يفعل كل شيء لحماية المطور ليس فقط من الزملاء ، ولكن أيضًا من نفسه (بالطبع ، أنا أمزح).
والنتيجة هي أنظمة برمجية يتم إنشاؤها لفترة طويلة ، من الحديد والخرسانة ، والتي يتم تغطيتها بعد ذلك بمئات من الاختبارات التلقائية ، ونتيجة لذلك قد يتضح أنه بمجرد اكتمال البناء ، تكون متطلبات الأعمال قديمة ، وتم حظر الأسلحة النووية ، وسيتم إغلاق مستودع وقود به جدران بطول 100 متر. على الفور إلى المتحف. ولكن غالبًا ما يكون هذا التصور للعالم - جيدًا ، على سبيل المثال ، في تطوير أنظمة متخصصة بشكل ضيق أو حيث تكون تكلفة الخطأ مرتفعة جدًا (البنوك ، إلخ).
في عالم اللغات الديناميكية مع الكتابة الصارمة / غير الصارمة (PHP ، JavaScript ، Python ، Ruby) ، مجموعة البديهيات مثالية ، من كلمة "بالكامل" ، أخرى:
- نحن محاطون بالأشخاص الأذكياء الذين يكتبون بشكل صحيح وأنيق على الفور
- هوس الاضطهاد (تغيير نوع المتغير الموجود أسفل القائمة ، والوصول إلى أعضاء الفصل المخفيين بواسطة مطور آخر بقصد "ضار" ، يلزم إعادة هيكلة الكود العميق ، وما إلى ذلك) - مرض تحتاج إلى محاولة التعافي منه بسرعة
- تصبح الأجهزة أرخص ، لذلك تحتاج إلى ترجمة البرنامج فقط على شكل قطع ، ثم إذا لزم الأمر
- لمزيد من التعليمات البرمجية ، والمزيد من الأخطاء ، لذلك يجب قراءة التعليمات البرمجية على الفور بشكل جيد ، تكون واضحة وموجزة ومثير
في عالم اللغات الوظيفية ، مثل Haskell / OCaml ، عليك أن تصدق ما يلي:
- يمكن التعبير عن أي مهمة حسب الوظيفة
- المتغيرات والدورات وقابلية التغيير - تؤدي إلى أخطاء (هذا في الواقع هكذا)
- البرمجة - للاختيار ويميل إلى التفكير التحليلي
نتيجةً لذلك ، بدلاً من النصوص البسيطة التي تم إعدادها "صنعت ودققت وقررت ونسيت" ، فإن العمل العلمي الحقيقي يبدأ في مكان العمل ويبحث البحث عن "وظائف الله" عن اهتمام كبير للتعبير عن الموقع ... بمجموعة من الوظائف دون متغيرات ، نجاح باهر!
بالطبع ، أنا أبالغ ، لكن لا يوجد دخان بدون نار. على الرغم من أن هذا النهج يعمل في بعض المهام بشكل
جيد ، ولم يأتِ أحد بأسلوب أفضل.
"الحروب الصليبية" في إدارة مشاريع البرمجيات
في مجال إدارة المشاريع ، فإن الوضع مغطى أكثر بالكآبة العلمية الزائفة. والسبب معروف: حل واضح وملقى على السطح ، حل بسيط وموجز للجبهة:
- فهم ما يريده العميل
- جذب المتخصصين وتقييم كمية العمل
- اكتب الكود
في الواقع ، لسبب ما ، لا يعمل :-)
يدرك المشاركون المتمرسون في فرق المشروع جيدًا أن العميل ، غالبًا ما يكون مبتذلًا ، لا يعرف ما يريده ، لأنه غارق في المشاعر ، ومشاكل الرياضيات المنسوخة في المدرسة ، مما أدى في النهاية إلى "ضمور جزئي لجزء الدماغ" المسؤول عن التعبير المتسق منطقيًا عن الأفكار. امتلاك شجارات شعرية ورسومات أحمر الشفاه وملاحظات على أوتار الجيتار ، بدلاً من المتطلبات الفنية للموقع ، يبكي المختصون حتى لا يضحكوا من العجز ، ويزيدوا تقديرات مقدار العمل بترتيب ضخم ، وفرض ضريبة على عدم كفاية ذلك ، وما إلى ذلك.
في ظل هذه الظروف من عدم وجود منطق صارم ورغبة ، أنا آسف لاستخدام رأسي للغرض المقصود ، كما لو أن قفزات وحدائق ، وتحدث انتهاكات غير علمية فظيعة في أسلوب علم التنجيم / الأعداد / pranyozhenie والكهانة على أساس القهوة.
عادةً ما يتم استغلال الانتهاكات بنشاط من قبل أشخاص واثقين جدًا قادرين على الإقناع جيدًا ، والذين لم يحملوا "الكود" (نعم ، أنا أتحدث عن رشيق خاطئ).
يقولون أنه في بعض الفرق قبل السباق ، تجبرنا أكثر المتحمسين المتحمسين لنا المهندسين على ، ومعذرة ، على علاج البول :-) ومع ذلك ، يتم
إنشاء هذه "الممارسات" بأنفسهم في كثير من الأحيان
بواسطة مطورين ذوي خبرة للغاية ، مثلهم مثل غيرهم ، يمكنهم استخدامها بشكل صحيح.
أنا هنا أحب القياس على nunchucks - يبدو كسلاح بسيط ، لكن القليل منهم فقط يمكنهم استخدامه بشكل صحيح ، ويصاب معظمهم بجروح ، آسف ، أنت تعرف ما أنت نفسك.
أسطورة أخرى هي التبادلية
في بعض الأحيان يحاولون إقناعنا
بتبادل المهندسين . من المعروف جيدًا أنه من أجل الحصول على فهم جيد وعميق لتكنولوجيا البرمجيات ، تحتاج إلى إعادة قراءة العديد من الكتب ،
والاستماع إلى عشرات الدورات التدريبية ، وحل عدة مئات من المشكلات ، والمشاركة في خمسة مشاريع برمجية ، واحد منها على الأقل قد وصل إلى خط النهاية. بعد ذلك - تبدأ التجربة ، والتي بعد 5 سنوات ، على الأقل ، تصنع التشفير - أخصائي.
عادة ، يعمل المطور باستمرار على المشاريع ، يتقن المطور لغة واحدة أو لغتين من لغات البرمجة والتقنيات ذات الصلة. النجاح والنمو المهني للمهندس يكمن بالضبط في تخصصه الضيق ، لأنه بالإضافة إلى اللغات نفسها ، من الضروري التعمق في مكتبات النظام ، والتي غالبًا ما تكون كثيرة جدًا والوثائق الخاصة بها واسعة جدًا.
تكمن المشكلة في أنه الآن ، لسبب ما ، من المألوف ألا تقرأ الكتب - ولكن جوجل وتطردها ، وليس بما في ذلك الدماغ ، بينما تستمني عقلياً في الشبكات الاجتماعية وإشعارات الهواتف الذكية.
أصبح العثور على أخصائي حقيقي يتعلم بشكل منهجي من القاعدة إلى القمة ، ببطء ولكن بثبات ، سد الفجوات في معرفته - أكثر صعوبة. للأسف ، السوق مليء بـ "علم النفس" بـ "أيدي مدللة".
ماذا تفعل؟ قيم البقاء الموصى بها
أولاً ، ليست هناك حاجة لليأس ومن المهم جدًا عدم الانغماس في العواطف. من الضروري أن نفهم بوضوح أن التطوير هو ، أولاً وقبل كل شيء ، رياضيات صارمة (عادةً على مستوى المدرسة) ومنطق بالمقاييس ، حيث ، باستخدام terver والحدس ، من الضروري التعامل مع المخاطر ذات الأولوية والرؤساء "الرطبين" في مرحلة الطفولة.
لقد اعتدنا أن نمارس الألعاب عبر الإنترنت من قبل ونجحت في العمل بشكل جيد - فبذل قصارى جهدك ، فبدلاً من الرؤساء سيكون لديك مشاريع برمجية ، وبدلاً من الأخطاء - zerg!
من الممكن دائمًا وضروريًا إدارة المخاطر بوعي ، ومن التجربة ، إذا تم القيام بذلك "بشكل منهجي وعلمي" ، فإن أي مشروع برمجيات سينطلق في الوقت المحدد ، أو سيتضح بسرعة لماذا لا يبدأ الصاروخ وما المشكلة / على وجه التحديد.
في ضوء ما تقدم ، نوصيك بالبدء في التقيد بالقيم التالية للنهج العملي التجريبي الوثيق ، والذي يتقاطع عن كثب مع النشيد المعروف للحس السليم - "
بيثون زين " و "
البيان الرشيق ":
- ابحث عن الحل الأبسط والأوضح
- أكثر وضوحا وأكثر صحة
- أصبح الأمر صعبًا - فهذا يعني وجود عضادة في مكان ما وتحتاج إلى مواصلة البحث
- الغطرسة - من انعدام الأمن أو الطفولة الصعبة
- قدرات الدماغ البشري محدودة ، خاصة تحت تأثير الهرمونات ، وفي بعض الفترات أيضًا
- من الكحول والتدخين - نحن نتخلى عن كثب
- نميل إلى نسيان بسرعة حتى ما عرفناه جيدًا وحتى مؤخرًا
- نسعى لتحقيق أقصى قدر من الشفافية والانفتاح
- نحترم بعضنا البعض
- شجع أسرع صعود ومناقشة للمشاكل في أوسع دائرة ممكنة - مثالية على الفور
- استخلص النتائج ولا تخطو على أشعل النار 3.14 مرة على التوالي :-)
جمع المتطلبات
بعد أن تعلمنا بعض الأسرار وميزات الاتجاهات في تطوير البرمجيات ، سننتقل بثقة - سنتعلم كيفية تجميع متطلبات النظام بشكل صحيح.
هل العميل قادر على التفكير من حيث المبدأ؟
لا شيء مضحك - لا يزال الوضع منتظمًا. والعميل في هذا السياق هو مفهوم جماعي. بادئ ذي بدء ، حاول تقييم مستوى التفكير المنطقي والقدرة على تركيز ممثلي العملاء. مع من ستعمل معه ومن سيساعدك؟ الخيارات الممكنة:
- حزب سياسي. من الضروري إجراء ، على سبيل المثال ، مشروع ويب بحلول التاريخ لأن شخصًا ما يريد / وعد بشيء ... المتطلبات غامضة ، ولا أحد يعرف التفاصيل ، ومن يعلم - سيتوقف منذ وقت طويل. تمت متابعة المشروع بواسطة فريق غادر وكان من المستحيل تقريبًا فهم ما رأوه. على الجدران - أدمغة مجففة من انتحار أحد كبار المبرمجين. الرمز سيء وهش ، تنبعث منه رائحة حتى تؤلم عينيك. في كثير من الأحيان في مثل هذه الحالة ، يحاولون العثور على "التضحية المقدسة" ، والتي يمكن إلقاء اللوم عليها في الأشهر الستة المقبلة و ... بدء البحث عن حل جديد. الشعور بالخوف والاكتئاب وقمع انفتاح العملية مع مزيج من الدم على الشفاه. لا يزال احتمال إنشاء حل برمجي في الوقت المحدد ، وإن كان صغيراً ، موجودًا - إذا قمت بذلك مرة أخرى في إطار جاهز مع وثائق جاهزة. عادة ما تكون الطريقة الوحيدة وليس وسيلة أخرى.
- تتواصل مع ممثلي العملاء وتفهم أنه من الصعب حقًا على الأشخاص التعبير عن أفكارهم الخاصة بشكل منتظم / رسمي ، والتي يتم خلطها بعد الجملة الثالثة ، ويتكرر ذلك في دوائر. بعد 15 دقيقة من الحوار ، تبدأ شكاوى الصداع. الضحك يسمع ، أجواء الحفل ، صورة شخصية ، كانت الحياة ناجحة ... لكن رغباتهم ، بشكل عام ، مفهومة وصادقة - تحتاج فقط إلى مساعدتهم قليلاً في الخروج بصرامة. عادة ما تكون احتمالية الإقلاع هنا أعلى منها في الفقرة 1 ، ولكن مرة أخرى ، عادة ما يساعد استخدام الحل الأكثر استعدادًا والمعبأ مع الوثائق الجاهزة والسيناريوهات النموذجية.
- يفهم العميل جيدًا ما يريده ويحاول التعبير عن أفكاره ورغباته منطقية ومتسقة. في هذا الأمر يساعده محلل غير مرتبك ، حيث يعرض أفكار الإدارة ويمررها كأفكار خاصة به. يوجد لدى فريق العميل خبير واحد على الأقل في مجال موضوعه (مضحك ، لكن هذا لا يزال وضعًا نادرًا للغاية). في هذه الحالة ، يكون احتمال مساعدة وحل المشكلة برمجيًا كبيرًا للغاية. يمكنك هنا المشاركة في التصميم والمناقشة المشتركة للمعاجم ونماذج الكائنات ونماذج البيانات وتدفقات البيانات وسيناريوهات اختبار التحميل. على الأرجح ، يمكنك جمع المتطلبات في وقت معقول.
نقطة أخرى مهمة هنا هي بناء علاقات ثقة مع العميل قدر الإمكان ، وإظهار انفتاحك ورغبتك في مساعدة العميل على التعبير عن أفكاره بوضوح. غالبًا ما يكون هناك نوع من التدريب الذي يتم من خلاله شرح ممثلي العملاء كيفية العمل باستخدام أدوات جمع المتطلبات التالية:
- مسرد عام
- نموذج بيانات منطقي يتم فيه تقديم علاقات تعدد صارمة بين عناصر المسرد (واحد إلى واحد ، واحد إلى كثير ، كثير إلى كثير)
- الأدوار واستخدام السلاسل التي تبين من يستخدم النظام وكيف
إنذارات من شأنها أن تشير إلى مشاكل وشيكة في جمع المتطلبات:
- يقوم ممثلو العملاء بترجمة "الأسهم" إلى بعضهم البعض ولا يمكنهم ربط الكلمتين ، فهناك الكثير من المشاعر - يوصى بتصعيد المشكلة في أسرع وقت ممكن والانتقال إلى مستوى أعلى - وإلا "كتضحية مقدسة" ، فسوف يتم تقديمك مع عبادة الفوضى و إجازة التقاعد / الأمومة. العمل في مثل هذه الظروف على Agile أمر خطير للغاية ، فمن الأفضل أن تكتب متطلبات فنية صارمة وأن تتحرك بخطوات صغيرة
- يستجيب ممثلو العملاء بأسلوب: أوه ، يؤلمك رأسك ، لكنك ذكي ، "مبرمج" ، لذا اجعله جيدًا. تحتاج هنا إلى طلب العثور على خبير في مجال الموضوع ، وهو المسؤول عن الإجابات نيابة عن العميل وبأسرع وقت ممكن. أو انظر الفقرة أعلاه.
- يفضلون عدم التحدث عن المشكلات (رمز غير قابل للقراءة ، وعدم وجود وثائق لعمليات الأعمال الرئيسية) ، لأنه تم إنفاق الأموال ، والمراكز التي تم تلقيها ، والمكافآت التي يتم التعبير عنها والتحدث علنيًا عن المخاطر يمكن أن تؤدي إلى التنظيف المكثف للموظفين (على الرغم من أن الجميع "يفهمون" ، وهنا المهندسون يدورون في البرميل) - يصعب تقديم المشورة هنا ، والتصرف بناءً على الطقس الفعلي
في الحالات السريرية المذكورة أعلاه ، مرة أخرى ، يساعد تطوير حل صندوق / سحابة جاهز مع وثائق جاهزة كثيرًا. مثل هذا النهج سوف يقلل من مخاطر التغييرات المفاجئة في الدورة بمقدار 180 درجة بأوامر من حيث الحجم. لكن الضمانات بالفعل أقل.
في حالة وجود نهج مناسب من جانب العميل ، والرغبة في تعلمك وفهمك ، والرغبة الصادقة في إطلاق مشروع في الوقت المحدد وتطويره أكثر ، فإن الاستخدام المتزامن لعدة منصات تقنية يساعد كثيرًا. لم يعد التصميم مخيفًا - فأنت تشعر أن العميل يشاركك مسؤولية تجميع المتطلبات معك بنسبة 100٪ ويمكنك محاولة القيام بها بشكل جيد. أنت - تؤمن بعضها البعض وتصارع سوية مع التعقيد:
- PHP الموقع مع الإطار ، حل محاصر
- التحليلات التنبؤية في بيثون
- تطبيق المحمول إما على نظام أساسي واحد يعمل في كل مكان ، أو نكتب لكل جهاز
لا تضيع الوقت!
إذا كان الأمر لمدة 2-3 أسابيع ، في الحالات القصوى ، لمدة شهر ونصف ، لا يمر شعور بأنك تشارك في المسرحية "الدردشة مع نظرة ذكية وتستغرق بعض الوقت ووضع كل شيء على شخص ما" ، وسحب رافعة الإيقاف ، وأشعل النار في القطار وأصرخ بصوت عالٍ في يصرخ: "العودة إلى المنزل ، والأطفال! انتهى الأداء. "
على محمل الجد ، قم بترتيب اجتماع مع إدارة العميل والإصرار على ضم عدد كافٍ من الموظفين في فريق المشروع ، والذين يفهمون بالتفصيل كيف يعمل العمل ويكونون قادرين على الإجابة عن الأسئلة التي يطرحها المهندسون بصرامة. أو استقال - أحيانًا ما تكون هذه هي الخطوة الصحيحة: احفظ وجهك وتنمو كأخصائي.
قائمة التحقق
نتيجةً لذلك ، يمكننا اعتبار عملية جمع المتطلبات ناجحة ومن المنطقي المضي قدماً إذا كنت ، مع العميل ، تمكنت من إعداد القطع الأثرية التالية في غضون أسبوعين:
- مسرد يسرد 50-150 مصطلحات المجال
- نموذج البيانات المنطقية مع علاقات مصطلحات المسرد
- استخدام الحالات مع مصطلحات المسرد
- للخوارزميات المعقدة - مخططات انسيابية أو مخططات نشاط UML
- واجهات نظام البرامج التي لا تتعارض منطقياً مع العناصر المذكورة أعلاه
- لقد قررت مجموعة من البديهيات التي تصف موقفك من العالم = اخترت تكنولوجيا البرمجيات. هنا ، كثيرون ، بسبب حب الإبداع ، ينجذبون إلى الماسو سادو والرغبة في إعادة اختراع العجلة - قاوموا هذه الرغبة. قرر: إما أن يكون العالم كله مليئًا بالخدع والأوساخ العظميين وجعل مخبأ يمكنه الصمود في وجه هجوم جسم غامض ، أو أن المطورين يرغبون بإخلاص في مساعدتك. أفضل تقنية ومجموعة من البديهيات: إطار عمل مطور أو حل محاصر جاهز - ستقل مخاطر عدم الإقلاع بأوامر من الحجم الضخم (في التجربة ، 95٪ وفوق المشاريع تنطلق)
- لقد فاتتك نظام البرنامج من خلال العميل ، بنفسك ، من خلال عقلك ، وليس هناك أي بقع موحلة أو طين عاطفي. إذا كانت هناك أماكن محتملة الفاسدة (ويحدث هذا دائمًا ، كقاعدة ، فعليك بإدراجها في خطة إدارة المخاطر والتحدث بها في كل اجتماع من اجتماعات المشروع. وتوقع أن تكون مؤطرًا وتأكد من أن تسأل كيف فاتتك
إذا تعذر جمع القطع الأثرية المذكورة أعلاه للفترة المحددة ، ولم يكن هناك سوى أوراق تغطي النقطة الخامسة مثل "أحمر الشفاه TK الغامض" ، فلن يتعاون المحللون مع بعضهم البعض ، ولا يتوقع الخبراء في مجال الموضوع من جانب العميل ، وتتعطل المشكلات ، ويسود جو من خلع النوافذ "الأخبار السارة فقط" - قم بحزم أغراضك: على الأرجح لن يسمح لك بالطيران ، تم تأجيل استكشاف القمر لفترة غير محددة من الزمن وأنت في أداء مسرحي لن تفرق ".
لتحقيق النجاح الحقيقي ، من المهم جدًا أن نحب أنظمة البرامج حقًا ، وأن نستسلم لتجميع المتطلبات والتصميم على أكمل وجه ، أتمنى أن تبدأ الصواريخ مبكراً ، وأن تشرب البيرة مع العملاء ، وأن تثق في بعضها البعض وأن تكرر باستمرار كلمات
Edsger Dijkstra : "البساطة هي المفتاح الموثوقية "!
مع Coming of all ونتمنى لكم حظًا موفقًا في تنفيذ مشاريع البرامج.