حقق منتجك ** الحد الأدنى القابل للتطبيق ** لاختبار مفهومك.
يجب أن يكون ** المحيط ** الخاص بـ MVP ** مخفض ** بينما يسمح لك بتسويق منتجك.
راهن على ** المُبدلين الأوائل ** واحصل على الحد الأقصى من ** الملاحظات **.
يتم نشر قناتك MVP وقابلة للاستخدام في ** الإنتاج **.
** Fail ** fast is ** learn ** fast.
** تجربة سريعة ** الحل (بضعة أسابيع) ، وجمع ** ردود الفعل ** من المستخدمين لديك والتعلم من أخطائك.
لا تخف من تغيير كل شيء **.
لا تنس ، سوف تفشل! **
** K ** eep ** I ** t ** S ** imple و ** S ** tupid.
** تجنّب الإفراط في الهندسة ** ، إذا كان نموذج "الورق" أو نموذج Google كافٍ لاختبار مفهومك ، فلا تذهب إلى أبعد من ذلك.
ابق بسيط! كلا من الناحية الفنية والوظيفية.
تحديد أقل ، ** توسيع المزيد **.
حدّد مواصفاتك إلى الأساسيات المجردة ، ** ركز على "ماذا" ** بدلاً من "كيف".
يجب أن يكون المنتج أكثر ** موثقًا ذاتيًا ** ممكن.
يجب أن يتم إصدار الوثائق بنفس طريقة التوليف.
دراسة منهجية ** حلول SaaS **.
** حلول SaaS ** ** مستدامة وفعالة من حيث التكلفة **.
في بعض الحالات ** SaaS ** يمكن ** تسريع ** تنفيذ ** MVP **.
التفكير في الرؤية الاقتصادية ** فيما يتعلق بالبدائل من حيث ** التكلفة الإجمالية ** (** TCO **: ** T ** otal ** C ** ost of ** O ** wnership ) وليس فقط من حيث تكلفة الترخيص.
يجب ألا يكون النشاط الأساسي ** ** عائقاً أمام بناء خدمات وتطبيقات جديدة.
يجب أن تكون سرعة تطور وتسليم الأعمال الأساسية متوافقة مع خفة الحركة ** للخدمات التي تستهلكها.
يجب أن تعرض الأعمال الأساسية ** الخدمات **.
يجب أن تتبنى الأعمال الأساسية مبدأ ** مدفوعًا بالأحداث ** ، حيث تقوم بالإبلاغ عن إجراءات الإدارة في شكل أحداث.
** النشر في الإنتاج ** هو حدث غير مناسب.
استفد من ** النشر المستمر ** للتكيف ** ** الإنتاج ** إلى ** متطلبات العمل ** وليس العكس.
** يجب أن تكون ** عمليات النشر ** عبر البيئات ، حتى ** الإنتاج ** ** تلقائية ** و ** متكررة **.
يسمح لك نهج ** بيتا ** الدائم بإشراك المستخدمين في عملية التطوير.
لا تتردد في استخدام مبدأ بيتا الدائم الذي يشارك فيه ** المستخدمون في التطوير **.
يشير مصطلح beta الدائم إلى تطبيق تم تطويره في الوقت المناسب ، ** يتطور باستمرار ** ، وليس منتجًا غير مكتمل.
تعتبر تجربة ** المتصورة ** من قبل المستخدم أمرًا أساسيًا.
** بيئة العمل ** غير قابل للتفاوض.
لا تهمل عمل ** المصممين UX ** ، إنه أمر أساسي في تطوير التطبيق.
دمج ** ردود الفعل ** من المستخدمين ، وهذا واحد ضروري.
استخدم ** واجهات قوية ** للاستخدامات الداخلية والخارجية.
وتوجه واجهات نحو ** الكفاءة **.
يعمل ** الأداء ** الخاص بواجهة على توفير الوقت ** ، ويزيد من ارتياح المستخدمين ** ** وبالتالي يوفر ** إحباطهم **.
اعتماد استراتيجية ** موبايل أولا **.
الأجهزة المحمولة هي أهم ** ** ** في ** السوق **.
يفكر التفكير المحمول في ** ضروري **.
** التصميم المستجيب ** هو القاعدة ، وهو مصدر للادخار (** MVP **).
بالتوافق مع الاستخدامات ، فإن ** omni-channel ** هي القاعدة.
يوفر نهج القناة الشاملة للمستخدم تجربة ** موحدة ** (على سبيل المثال: Netflix).
القنوات ** المختلفة ** ** متزامنة ** و ** متماسكة ** (على عكس عمليات الدفعية).
جميع الجهات الفاعلة (العملاء والمستشارين) الوصول إلى نفس المعلومات.
** ** ** ** ** ** ** مالكي ** من بياناتهم ودورتهم.
اترك ** أفراد ** ، في أي وقت ، ** تحكم ** على بياناتهم ** ** الشخصية.
إنشاء ** الثقة ** عن طريق السماح للمستخدمين بالتتبع والتحكم في الوقت الفعلي.
** يجب أن تفي الأنظمة الفرعية ** بنفس المتطلبات.
يجب أن تكون علاقة العميل موحدة ومُحسنة مع نظام إدارة علاقات العملاء (CRM / SFA) المرنة والموحد والموجه للأحداث **.
اختر ** CRM ** الذي يدير علاقات العملاء وقيادة المبيعات (** SFA **: ** S ** ales ** F ** orce ** A ** utomation ).
** يجب أن يكون ** CRM ** مفتوحًا ** للفرص الجديدة.
** ينتج ** CRM ** أحداث ** تتوافق مع إجراءات الإدارة لتتناسب مع المنطق ** المنبثق عن الحدث ** للمنصة.
تتيح لك منصة البيانات الكبيرة إمكانية مركزية ** ومعالجة بيانات المستخدم لتقديم أفضل خدمة لرحلتك **.
Centralize ** Maif Group **، ** Partner ** and ** Vendor ** data in a ** pathway ** logic.
يمكن "تجهيز البيانات" والمعالجة ** دمج ** البيانات.
** تتعاون فرق البيانات الكبيرة ** مع فرق العمل المميزة لضمان إدارة البيانات ** **.
تم تكييف محطة العمل وتكييفها مع ** الاستخدامات ** و ** القنوات الحديثة **.
اعتمد ** اتحاد الهوية ** للحصول على تجربة موحدة.
يسمح ** portal ** بتقديم ** نظرة عامة ** ، لا يحل محل التطبيقات.
يجب أن تكون محطة العمل ** ** ، ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **.
لا تنس أن شركاءك ** يستخدمون تطبيقات حديثة في المنزل في UX.
تعامل مع جميع مستخدميك كـ "عملاء" **: مستخدمي الإنترنت ، والمديرين ، والتشغيل ، والمطورين ، إلخ …
لا تقلل من شأن جهد ** UX ** لتنفيذ تطبيقات إدارة الاستخدام الداخلي.
كل ما يمكن قياسه يجب أن يكون.
** بدون قياس ، كل شيء هو فقط رأي **.
فكر في المقاييس أثناء ** تطوير ** التطبيق. ** يجب أن يكون للسجل ** ** بالإضافة إلى البعد التقني **.
لا تهمل مقاييس الأداء ** ، فهي أساسية.
يوفر فريق الميزات ** عملية **: فهو مسؤول عن جعل ** التطبيق قابلاً للاستخدام **.
** يوفر اختبار A / B ** الوقت الذي يسمح بتحديد ** الملاحظات **.
بدلاً من الحكم التعسفي بين حلقتين ، لا تتردد في إعداد ** A / B testing **.
يتكون هذا النمط من تقديم نسختين مختلفتين ** من نفس التطبيق واختيار أحدهما بناءً على ** المقاييس الموضوعية ** لنشاط المستخدم.
** النظر في تدهور ** بدلا من انقطاع الخدمة في حالة الفشل.
في ** الفشل ** لواحد من الأنظمة الفرعية ، ** يجب اعتبار ** نسخة متدهورة من الخدمة ** في المقام الأول بدلاً من الانقطاع.
مع ** قواطع دوائر ** ، ** عزل الانهيار ** إلى ** تجنب ** تأثيره ** و ** الانتشار ** على كامل ** النظام **.
يتم تنظيم الفريق حول ** product ** أو ** service ** تم تقديمه.
الفرق هي ** فرق عمل ** ، منظمة حول مجموعة وظيفية متماسكة ، وتتألف من جميع المهارات ** الضرورية لهذه المجموعة.
على سبيل المثال: Business Expert + Web Developer + Java Developer + Architect + DBA + Operational.
** المسؤولية ** هي ** جماعية ** ، يمتلك فريق الميزة القدرة اللازمة لهذه المسؤولية.
الحد من ** حجم الفرق المميزة ** (من 5 إلى 12 شخصًا).
الحد من حجم "فريق ميزة": ** بين 5 و 12 شخصًا **.
أقل من 5 ، هي حساسة جدا للأحداث الخارجية ويفتقر إلى الإبداع. وفوق 12 عامًا ، تفقد الإنتاجية.
يشير المصطلح ** "2-Pizza Team" ** إلى أنه يجب ألا يتجاوز حجم "فريق التميّز" عدد الأشخاص الذين يمكن إطعامهم ببيتزا.
راهن على الأشخاص المتنوعين الذين يعرفون كيف يفعلون ** ويريدون فعله **.
الأهم هو ** ثقافة التطوير ** ، ** قابلية التوسع ** و ** القدرة على التكيف **.
تجنيد ** الحرفيين البرمجيات والمطورين كامل المكدس ** ، فإنها تجلب قيمة مضافة حقيقية من خلال معرفتهم ورؤيتهم الشاملة.
ومع ذلك ، فإن مطوري الأجهزة المحمولة - على سبيل المثال - يكونون عادةً ** مطورين متخصصين **.
يكون ** جذاب ** لتوظيف ** أفضل **.
اقتراح وسائل عمل ملائمة للموظفين: ** التنقل ** ، ** العمل في المنزل ** ، ** CYOD ** (** C ** hoose ** Y ** our ** O ** wn ** D * * افيسي).
إتاحة الوقت للتجريب وجعله يحدث ** في وقت العمل **.
يجب أن تكون المنظمة ** محرك للنوم **
اليوم السابق هو جزء من العمل.
يجب أن تكون المؤسسة محرّكًا للعناية اليومية ** ** من خلال إنشاء أنظمة مثل ** التعليم المستمر ** أو ** جامعات الأعمال **.
لا تتردد في الجمع بينها وبين الطرق الأخرى ** غير الرسمية ** مثل: ** Coding Dojos **، ** Brown Bag Lunchs **، ** External ** Conferences.
كسر الحواجز بين الصفقات ، راهن على أهداف ** التقارب **.
لكسر الحواجز بين الحرفين ، لا يكفي تجميع الناس حول منتج مشترك في مكان عام.
تزيل ** المقارنات الرشيقة ** هذه الحواجز لضمان تقارب الأهداف **.
هذه الممارسات هي جزء لا يتجزأ من مفاتيح النجاح ، والمؤسسة هي الضامن.
** تسمح ممارسات DevOps ** للجدران بالهبوط بين البناء والتشغيل.
تعتمد ** DevOps ** على التقارب ** Dev ** و ** Ops ** نحو هدف مشترك: ** تخدم المنظمة **.
** تبقى التداولات مختلفة **! لا يعني DevOps أن الشخص نفسه يقوم بمهام Dev و Ops. ** يجب على المطورين ** و ** التشغيلي ** ** ** أن يتعاونوا ** لكي يستفيدوا ** من ** ** ** ** من أجل تحسين ** التعاطف **.
** يتم تنفيذ المهام الصعبة ** بواسطة فريق الميزات **.
يتبع الأتمتة.
في التنظيم التقليدي ، ** يرتبط الافتقار إلى الفهم ** بين الفرق عادة بالمسافة و ** عدم التواصل **.
إن ** أعضاء فريق عمل الميزات ** هم ** المسؤولون ** و ** متضامنون ** لجميع المهام.
** الألم ** هو عامل رئيسي في ** التحسين المستمر **.
يصعب التوفيق بين مراكز الخدمة وبين الالتزام ** **.
تستند الفرق المميزة حول المبادئ التي تعتمد بشكل كبير على ** التعاون ** و ** المشاركة الجماعية **.
وتتجه مراكز الخدمة نحو ترشيد ودمج تكنولوجيا المعلومات من قبل قطاع الأعمال ، وهو ما يتعارض مع مفهوم الالتزام الجماعي هذا.
المنظمة لديها ** دور المصادقة ** ، دون أن تكون دغمائية.
تأكد من أن المنظمة تحتفظ بدورها المصادق عليه ** على الأدوات والاستخدامات. على وجه الخصوص على ** الأدوات التي تؤثر على التراث ** (مثال: إدارة شفرة المصدر).
** تقديم ** فرق ميزة مع ** يعني ** لدعم خياراتهم.
لا تكون ** دغمائية ** وتأكد من ** تشجيع التجريب **.
من المتوقع أن تقوم ** الفرق ** بالتواصل ** ومشاركة تجربتها ** ** ** **.
لا تقم بإنشاء حواجز بين ** Feature Teams **.
قم بإعداد ** مؤسسة ** و ** خفة الحركة ** اللازمة للفرق المميزة للتواصل مع بعضها البعض ومشاركة مهاراتهم وخبراتهم.
تنظيم التبادلية في ** Spotify ** (القبائل ، الفصول والنقابات) هو مثال بليغ **.
** واجهات برمجة التطبيقات لجميع الاستخدامات **: الداخلية ، والعملاء والشركاء ، العامة.
افتح مؤسستك لاستخدامات جديدة وعملاء جدد باستخدام ** Public APIs **.
في ** الشراكات ** التجارية ** ، ** العملاء ** كموفرين ** ** ، APIs هي تنسيق تبادل قياسي.
** الغرض من APIs ** هو استخدامه أيضًا في ** الاستخدامات الداخلية للمؤسسة.
يجب أن يكون استخدام واجهة برمجة التطبيقات ** بسيط ** و ** سريع **.
يجب أن يكون استخدام واجهات برمجة التطبيقات أبسط ما يمكن. فكر في تجربة مطوري ** **.
أفضل حل للتحقق من مدى كفاية الاحتياج هو ** اختبار واجهة برمجة التطبيقات بسرعة **: بضع دقائق يجب أن تكون كافية!
يجب أن توفر المنصة واجهة رسومية ** ** لاختبار واجهة برمجة التطبيقات ببساطة.
يجب أن يتم التحكم في استخدامات واجهات برمجة التطبيقات ** و ** يتم التحكم بها **.
تنفيذ حل إدارة API لإدارة ** الحصص ** ، ** الاختناق ** ، ** المصادقة ** ، و ** تسجيل **.
اجمع المقاييس لإدارة ** Monitoring ** و ** filtering ** و ** reporting **.
اضبط ** متطلبات ** للأنظمة والخدمات الخارجية ** المضمنة في المنصة.
يتطلب ** أنظمة خارجية ** لتلبية نفس ** متطلبات ** كما ** أنظمة داخلية **.
يجب أن تقوم الأنظمة الخارجية بنشر ** الأحداث ** والسماح ** المراقبة الفنية **.
في الحالة التي يجب فيها دمج بيانات الأنظمة الخارجية ، يجب أن يكون ** total ** synchronization ** ممكن **.
يجب التفكير في العمارة ** متعدد المستأجرين **.
حتى إذا لم يتم اعتبار العلامة البيضاء في القاعدة ، قم بإعداد بنية متعددة المستأجرين. التطبيق ** الأولي ** هو أول ** عقد **.
فكر في ** instantiation متعددة الوظائف ** للنظام من البداية.
يجب أن تكون الأنظمة قابلة للتهيئة أصلاً **.
** يجب أن تكون اللغات ، والعملات ، وقواعد العمل ، وملفات تعريف الأمان ** بسيطة.
احذر من ** جنسه الفائقه ** ، غالبا ما تكون عديمة الجدوى و ** مصدر التكلفة **.
يجب أن يكون ** الإعداد ** ** قابلاً للتحجيم ** وبسرعة حسب الحاجة.
إنشاء أنظمة مرنة وعامة باستخدام ميزة ** التقليب **.
** ميزة التقليب ** تدور حول تصميم التطبيق كمجموعة من ** الميزات ** التي يمكن تمكين ** ** أو ** تعطيل ** الساخنة ، ** الإنتاج **.
في تطبيق ** متعدد المستأجرين ** ، ميزة التقليب تسمح لك بتخصيص ** الداعمين **.
ميزة Le flipping ** simplifie l'A / B testing **.
** ** ** الخيارات الفنية ** ** ** ** ** ** ** ** ** ** من قبل ** Feature Team **.
يجب أن يتصرف فريق الميزات ** بمسؤولية ** لتحديد الاختيارات التي تؤثر بشكل حصري والخيارات التي تؤثر على المؤسسة.
يجب أن تكون ** الاختيارات ** ** التي تتجاوز ** نطاق فريق الميزة (على سبيل المثال ، الترخيص ، لغة البرمجة النادرة) ** مصادق عليها ** من قبل المنظمة أو من خلال عملية التقارب بين الأقران .
تمثل الأداة المناسبة ** ** ** الاستخدام الجيد ** مصدرًا للوفورات.
** ** أداة سيئة ** مفروضة على الجميع ** خطر **. يمكن أن يؤدي ** سوء الاستخدام ** للأداة الجيدة ** ** إلى عواقب مؤذية **. على سبيل المثال ، الطرق رشيقة المستخدمة بشكل سيئ خطرة.
** ** يجب أن تكون ** أسئلة **.
** Excel ** غالبًا ما يكون خيارًا عقلانيًا ** ولكنه ليس ** أداة لفعل كل شيء ** (CRM ، ERP ، Datamart ، …)
امتياز ** Build ** للأعمال الأساسية.
خذ بعين الاعتبار ** اشتر ** للبقية ، كل حالة على حدة.
كلما زادت الأداة التي تحمل ميزة ** تميز ** للمؤسسة ، كلما كان الغرض منها ** تم بناؤه **. يجب أن تسمح الأعمال الأساسية بنوعية ** ** و ** تتكيف بسرعة وفي كثير من الأحيان **. بعض ** حزم البرامج ** ** تتكيف في بعض الأحيان ** مع هذه الحاجة.
** ** بقية **: SaaS، Open Source، Build أو Owner يجب دراستها ** حسب الحالة **.
** الاستفادة القصوى من المصدر المفتوح **.
يجب أن تكون الخيارات البديلة مدعومة.
تمثل ** الحلول الخاصة ** ** ** للمؤسسات التي يجب أن تكون قادرة على استئناف الصيانة إذا لزم الأمر.
هناك عدد قليل من أدوات الملكية التي لا تحتوي على ** بدائل مفتوحة المصدر **.
تستفيد المنظمة ** من ** مجتمع المصدر المفتوح ** ويمكن ** تسديد مساهماتها **.
تطوير ** قائمة بذاتها ** و ** خدمات مقترنة بشكل ضعيف **.
** يجب أن يكون الاقتران الضعيف هو القاعدة.
لكل خدمة مصغرة واجهة ** محددة بوضوح **.
تحدد هذه الواجهة ** ** ** الرابط ** بين ** الخدمات المصغرة **.
** يسمح لك Domained Designed ** ، خصوصًا مع ** Contrast Contexts ** ، بتوقع هذه المشكلة.
كل خدمة لها نظام تخزين بيانات خاص بها **.
A ** Data Store ** يُقصد به أن يكون ** مقترنًا ** فقط ** ** ** مع خدمة مصغّرة واحدة **.
يتم الوصول ** إلى البيانات ** من خدمة مصغرة إلى أخرى ** حصريًا عبر واجهتها **.
هذا التصميم يعني ** التناسق مع مرور الوقت ** عبر النظام الأساسي. يجب أن يتم القبض ** على جميع المستويات ** ، بما في ذلك UX.
يجب أن يكون لكل خدمة ميكروية محيط وظيفي معقول ، والذي ** "يتناسب في الرأس" **.
توفر الخدمة الصغيرة ** عددًا معقولًا من الميزات **.
** لا تتردد في خفض ** خدمة صغيرة عندما تبدأ في النمو.
خدمة ذات حجم معقول تجعل من الممكن ** النظر ** بهدوء ** إعادة الكتابة ** ، إذا دعت الحاجة إلى ذلك.
يفتح ** Reactive Manifesto ** الطريق نحو تصميم البنى التفاعلية.
** يركز برنامج ** مستجيب ** على تدفق البيانات ونشر التغير. ويستند إلى نمط "** Observer " خلافا للنهج " Iterator **" ، أكثر تقليدية.
يحدد البيان التفاعلي المحاور الأساسية: ** التوافر ** والسرعة ، ** المرونة * إلى الأعطال ، ** المرونة ** ، ** المرونة ** و ** توجيه الرسالة **.
** العمليات غير المتزامنة ** تفضل ** الفصل ** و ** التدرجية ** لصالح ** الأداء **.
يجب أن يكون التبادل بين التطبيقات ** غير متزامن ** أولاً.
التبادلات غير المتزامنة بشكل طبيعي ** تسمح ** بالاقتران ** الضعيف ، ** العزل ** و ** التحكم في التدفق ** (** الضغط الخلفي **).
** يجب اعتبار الاتصال المتزامن ** فقط ** عندما يتطلب الإجراء **.
يجب توجيه نظام المعلومات ** الأحداث **.
يسمح ** توجيه الحدث ** بتفضيل تنفيذ طرق مثل ** C ** ommand ** Q ** uery ** R ** esponsibility ** S ** egregation (** CQRS ** ) و ** Event Sourcing **.
امتياز ** رسالة بسيطة ، قوية وقوية ** سمسار إلى "الأنابيب الذكية".
** أظهر ** ESB ** حدود **: ** صيانة قابلة للتحديث ** هي ** حرجة ** ، من وجهة نظر ** تقني ** ** ** و ** ترتيبي **.
** ** ** ** رسائل الوسيط ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
** نقاط النهاية الذكية ** و ** المواسير البسيطة ** هي بنية تعمل على نطاق واسع: إنها ** الإنترنت **.
ينبغي التفكير في ** المزامنة الكاملة ** للنظام بمجرد تصميمه **.
إذا كان التزامن ** بين نظامين مضمونًا بتدفق الحدث ** ، فيجب أن يكون ** resynchronization ** الكلي لهذه الأنظمة ** مُخططًا في وقت التصميم **.
تدقيق تلقائي ** ** ** للتزامن ** (مثال: عن طريق العينات) يسمح بـ ** بقياس ** و ** كشف ** أي أخطاء محتملة ** للمزامنة **.
** ** ** ** ** ** ** ** ** من الخدمات ** ** ** ** ** ** ** ** ** ** ** ** يضمن ** ** **.
** ** ** ** ** الخدمات ** ** ** ** ** ** ** ** ** ** لجميع البيئات **.
يضمن ** دليل ** مركزي ** ** اكتشاف ديناميكي ** من ** خدمات مصغرة **.
** ** ** ** قابلية ** يعتمد على هذا ** الدليل **.
توفر الفرق المميزة ** sandboxed ** بيئة.
تحافظ فرق العمل على بيئة ** sandbox ** (الإصدار الحالي والإصدار القادم) للسماح للفرق الأخرى ** بزيادة حجمها **.
في ** بعض الحالات غير الاسمية ** ، ** قد تكون ** ميزات ** معطلة ** في بيئة ** التطوير **.
** سوف يتلف نظامك! **
صممه بحيث يكون متسامحًا.
سوف ينهار نظام ** الخاص بك ** ، إنه أمر لا مفر منه. يجب أن تكون مصممة لهذا (** تصميم للفشل **).
التنبؤ ** التكرار ** على جميع المستويات: ** الأجهزة ** (الشبكة ، القرص ، الخ …) ، ** التطبيقات ** (حالات متعددة من التطبيقات) ، ** الجغرافية ** المناطق ، ** مزودي الخدمة ** (على سبيل المثال: AWS + OVH).
توفير ** مجموعة أدوات ** ، لا تفرض أطر صارمة.
** الاهتمام بالمنازل الفنية والمساكن المستعرضة **! فهي مقيدة ومكلفة ومن الصعب صيانتها.
** مسرعات ** ، ** مجموعة أدوات ** ، ** مداخن تقنية ** يمكن أن تكون مجمعة ** ، ** مجانية ** فرق مميزة ، تتجنب النهج العقائدي.
عامة أو خاصة أو مختلطة ، فإن ** cloud ** (** IaaS ** أو ** PaaS **) هو المعيار القياسي للإنتاج.
** تتيح لك خدمات IaaS ** معالجة الحالات التي تتطلب مرونة أكبر ** ولكنها تتطلب المزيد من العمل التشغيلي.
لا تعد السحابة الخاصة بيئة افتراضية تقليدية ، بل تعتمد على ** الأجهزة السلعية **.
لا تقوم الفرق المميزة بإدارة البنية الأساسية ، وإنما يتم توفيرها من قبل المنظمة **.
مشاكل البنية التحتية ليست ضمن ** فرق العمل **. يجب توفير البنية التحتية ** ** و ** صيانتها ** عبر خدمة ** وظيفية.
** توفر الحاويات ** المرونة اللازمة للأدوات غير المتجانسة.
توفر الحاويات المرونة ** التي تحتاجها فرق العمل لتمكن الأدوات غير المتجانسة ** في سياق متجانس **.
استخدام ** الحاويات ** يجعل من الممكن التغلب على مشاكل ** البيئات التقنية **.
الحاويات (مثال: ** Docker **) تجعل من الممكن ** أن تتحرر ** من اختلافات البيئة.
يجب أن تكون ** عملية النشر ** ** معروضة ** على البيئة.
** يجب عدم نشر بعض المكونات ** مثل قواعد البيانات في الحاويات. انتشارها لا يزال الآلي.
يجب أن تكون التدابير ** ** ** و ** يمكن الوصول إليها ** للجميع.
** ** ** ** ** يمكن الوصول ** إلى كل شخص بمستويات مختلفة من الدقة: عرض تفصيلي لميزة الفريق ذات الصلة ، وتجمعات لأعضاء آخرين في المنظمة.
لا يعني الوصول إلى ** المقاييس الوصول إلى بيانات الوحدة ** ، بل يجب التحكم في الحفاظ على السرية.
** تتأثر جميع البيئات **.
** جودة البرمجيات ** هي ** عامل رئيسي **.
** مراجعات الكود ** هي ** منهجية **. يتم إجراؤها بواسطة أعضاء فريق الميزة أو أعضاء آخرين في المنظمة ، كجزء من ** التحسين المستمر **.
هذا ** لا يتم تدقيقك لكن كودك **: "أنت لست رمزك!".
** يمكن أن تكون * qualimetry ** مؤتمتة جزئيا ، ولكن لا شيء يتفوق على ** "العين الجديدة" **.
** اختبار تلقائي ** هو متطلب سابق غير قابل للتفاوض للنشر المستمر.
يضمن الاختبار التلقائي ** ** ** جودة المنتج ** مع مرور الوقت **.
هو ** شرط أساسي ** للنشر المستمر ، فهو يسمح ** ** التغييرات ** و ** النشر المتكرر **.
يصبح طرح ** الإنتاج ** ** حدثًا كاذبًا **!
** الاختبارات على جميع المستويات **: الوحدة ، والتكامل ، والوظيفية ، والمرونة ، والأداء.
تعتبر اختبارات ** الدمج ** و ** الوظيفية ** هي الأكثر أهمية ، ** تضمن ** ** ** فعالة **.
** اختبارات ** وحدة ** مناسبة لتطوير ** **.
** اختبارات الأداء ** تقيس الأداء ** مع مرور الوقت **.
** تساعد اختبارات المرونة ** على توقع ** حالات الفشل **.
** الغلاف ** هو مؤشر الهدف الأساسي لجودة الاختبار.
تُعد تغطية ** الكود ** بواسطة الاختبارات مقياسًا ** جيدًا ** لجودة الشفرة.
هذا ** شرط ضروري ** لكن ** غير كاف ** ، يمكن أن تكون تغطية إستراتيجية اختبار ** سيئة ** عالية بدون ضمان الجودة الجيدة للشفرة.
** الأمان ** هي ** عملية ** ، لا ينبغي أن تعالج استجابة للمشاكل.
** ** يمكن ** أن يكون خبراء الأمان ** متكاملة ** مباشرة في فرق العمل ** إذا لزم الأمر **.
** خبراء الأمن ** متاحون في المنظمة من أجل ** التدقيق ** ، ** الوعي ** و ** إلى الأمام **.