عقلية رشيق مقابل آليات رشيق

https://flic.kr/p/bkcj5q

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

أنا أعتبر نفسي مؤهلا إلى حد ما لتقديم هذه البصيرة. أنا ممارس رشيق من الأيام التي تشارك فيها تطوير Agile باستخدام مفك البراغي - لتفكيك مقصوراتك ووضع خطة جلوس مفتوحة!

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

كيف يمكن أن تتطور عملية تطوير البرامج من https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

في هذا الوقت تقريبًا ، سمع فريقي عن شيء يسمى "بيان Agile" وممارسة تسمى "البرمجة المتطرفة". نظرًا لتوقيعه من قبل قدامى المحاربين في الصناعة الذين كنا نقرأ كتبهم بنشاط ، فقد قدم أشخاص مثل مارتن فاولر وكينت بيك هذه الممارسة كثيرًا من الشرعية. قام فريقي المكون من خمسة أفراد بتفكيك مقصوراتنا ، وتم سحبها من مكتبنا (الوكيل لعميلنا) ليجلس إلى جوارنا ، وإنشاء لوحة مع بطاقات الفهرسة وذهب إلى العمل ، مما يجعل XP في طريقنا. كان لدينا دورة أسبوعية من التخطيط والعروض التوضيحية ، والكثير من الاقتران والمناقشة. عملت في العديد من التكرارات وأشكالها المختلفة في شركات مختلفة لمدة 15 عامًا تقريبًا. يبدو أن أحد الفريقين لم يتبع أي منهجية على الإطلاق ، ولكن السبب في ذلك هو أن جميع أعضاء الفريق كانوا من خلفية عميقة ، وأن التكرار والتعاون كان حالتهما الافتراضية في التشغيل ولم يحتاجا إلى عملية مفروضة.

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

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

ما يتعين علينا القيام به هو

  1. حدد المشكلات التجارية الأساسية التي نريد حلها باستخدام الكود
  2. تقديم حل نظري بسرعة لاختبار الفرضية
  3. تكرار وتتكيف مع تغير الاحتياجات ، أو نتعلم المزيد
  4. قم بذلك بالتعاون مع العميل الذي شارك في الفريق

كل ما نقوم به هو جعل 2 و 3 أعلاه أقل إيلامًا - لمعرفة ما إذا كنا نلبي الحاجة في أسرع وقت ممكن ، وإذا لم نتمكن من التغيير بسرعة. إذا قررت إنشاء (مقابل شراء) ، فأنت تكتب برامج مخصصة. وهذا يعني أن لديها متطلبات وبيئات متخصصة.

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

فيما يلي بعض الآليات الأخرى الضرورية لسرعة الحركة

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

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

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

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

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

تذكر
رمز جيد يمكن تغييرها بسهولة

أفضل رمز يمكن حذفها بسهولة

أفضل رمز هو الذي لم يكتب على الإطلاق

من الضروري أن تقابل البتات التي تنشئها العالم الواقعي في أقرب وقت ممكن ، حتى تعرف شكل البتات الجديدة ، ولا تضيع الوقت في إنشاء البتات غير الضرورية.