سحر الاحتشاد السريع

كونك فريق تطوير برمجيات رشيق يعني بالتأكيد أشياء مختلفة لأناس مختلفين. هناك درجات من التبني عبر طيف واسع جدًا ، مع وجود عدد قليل جدًا من المنظمات التي تعتقد أنها تقوم بذلك بشكل جيد. وفقًا لمسح حالة Agile الخاص بـ VersionOne (الصادر في أبريل 2017) ، قال 80٪ من المشاركين في الاستطلاع إنهم "عند مستوى النضج أو أقل منه". لسوء الحظ ، غالبًا لا تبذل فرق التطوير الكثير من الجهد في جزء "التعلم" من التكرار. نريد أن نسرع ​​وننهي احتفالات سكرم حتى نتمكن من العودة إلى كتابة الكود. بعد كل شيء ، هناك الكثير من العمل للقيام به! ولكن هل يمثل وقت الترميز غير الكافي المشكلة حقًا؟

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

مبادئ في التنمية الفعالة

بيكساباي

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

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

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

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

الاحتشاد التقليدي

بيكساباي

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

الحصول على إلغاء الحظر

بيكساباي

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

وهنا بعض الأمثلة:

1. تم نشر واجهة مستخدم وظيفية w / Stubs

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

2. نشر واجهات برمجة التطبيقات (APIs) للخلفية (بيانات ثابتة ومحددة الترميز)

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

3. قم بإنشاء إصدار HelloWorld من التطبيقات والخدمات الجديدة.

إذا كانت هناك حاجة إلى خدمة جديدة (مثل خدمة مصغرة) ، فأنشئ الريبو وأنشئ نسخة من الخدمة "hello world". يسمح هذا لموارد dev-ops بالبدء في مهام Jenkins ونصوص النشر قبل تطوير الخدمة فعليًا.

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

قم بتغليفه

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

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

1. كيف ننظم مهام هذه القصة لجعل العديد من الأشخاص يساهمون في وقت واحد؟
2. ما هو الحد الأدنى الذي يتعين علي فعله لإلغاء حظر شخص ينتظرني؟

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

© 2017 مايك شوميماك