एक अनुवादक से: यह DIB गाइड: डिटेक्टिंग एजाइल बीएस (संस्करण 0.4) है , जिसे 9 अक्टूबर, 2018 को अमेरिकी रक्षा नवाचार समिति (DIB) ने सार्वजनिक रूप से प्रकाशित किया था।

चुस्त सॉफ्टवेयर विकास में एक चर्चा है, इसलिए सभी रक्षा मंत्रालय के सॉफ्टवेयर प्रोजेक्ट अब लगभग "लचीले" होने के लिए डिफ़ॉल्ट हैं। यह दस्तावेज़ कार्यक्रम प्रबंधकों और रक्षा मंत्रालय के विशेषज्ञों को फुर्तीली की आड़ में "झरना" या "सर्पिल" ("फुर्तीला-गिरना") का उपयोग करने वाली परियोजनाओं से वास्तव में लचीली कार्यप्रणाली के साथ सॉफ्टवेयर परियोजनाओं को अलग करने में मदद करेगा।

सिद्धांत, मूल्य और उपकरण

चंचल विशेषज्ञ और उत्साही प्रमुख मीट्रिक की पहचान करते हैं जो इस संस्कृति और चुस्त विकास के दृष्टिकोण को चिह्नित करते हैं। अपने काम में, DIB ने अपने स्वयं के दिशानिर्देश विकसित किए हैं जो मोटे तौर पर एजाइल के वास्तविक मूल्यों को दर्शाते हैं:

फुर्तीला मूल्य	DIB सिद्धांत
व्यक्तियों और इंटरैक्शन प्रक्रियाओं और उपकरणों की तुलना में अधिक महत्वपूर्ण हैं	"योग्यता प्रक्रिया से अधिक महत्वपूर्ण है"
पूर्ण प्रलेखन की तुलना में रनिंग सॉफ्टवेयर अधिक महत्वपूर्ण है	"परियोजना की शुरुआत से सरलतम बुनियादी कार्यक्षमता की तैनाती के लिए समय कम करें"
एक अनुबंध सहमत करने के लिए एक ग्राहक के साथ सहयोग	"सॉफ्टवेयर सिस्टम के लिए DevSecOps संस्कृति का कार्यान्वयन"
योजना में बदलाव का जवाब	"कार्यक्रम छोटे शुरू होने चाहिए, पुनरावृत्त होना चाहिए, और सफलता पर निर्माण करना चाहिए - या वे जल्दी से वापस आ गए हैं।"

मुख्य संकेत कि परियोजना बहुत लचीली नहीं है:

• विकास टीम में से कोई भी उपयोगकर्ताओं के साथ संचार नहीं करता है या कार्रवाई में सॉफ़्टवेयर को ट्रैक करता है; हम वास्तविक कोड के वास्तविक उपयोगकर्ताओं का मतलब है। (कार्यक्रम मूल्यांकन विभाग को एक वरिष्ठ अधिकारी की तरह वास्तविक उपयोगकर्ता नहीं माना जाता है, जब तक कि वह अपने काम में कार्यक्रम का उपयोग नहीं करता है)। उपयोगकर्ताओं के साथ संचार के लिए स्वीकार्य विकल्प: अपने काम की निगरानी करना, प्रतिक्रिया और अन्य अनुसंधान विधियों के लिए उनके लिए प्रोटोटाइप पास करना जिसमें बहुत अधिक मौखिक संचार शामिल नहीं है।
• विकास टीम (बग रिपोर्ट, रेटिंग) के लिए उपयोगकर्ताओं से कोई निरंतर प्रतिक्रिया नहीं है। आवश्यकताओं की जांच करने के लिए परियोजना की शुरुआत में एक बार बात करना पर्याप्त नहीं है!
• जितनी जल्दी हो सके कम से कम उपयोगी परिणाम प्राप्त करने की तुलना में अनुपालन अधिक महत्वपूर्ण माना जाता है।
• हितधारक (विकास, परीक्षण, DevOps, सुरक्षा, ठेकेदार, अंतिम उपयोगकर्ता, आदि) अधिक या कम स्वायत्तता से काम करते हैं (उदाहरण के लिए, "यह मेरा व्यवसाय नहीं है")।
• अंतिम उपयोगकर्ता विकास में शामिल नहीं हैं; कम से कम, उन्हें रिहाई की योजना और स्वीकृति परीक्षण के दौरान उपस्थित होना चाहिए।
• ऐसी पर्याप्त DevSecOps संस्कृति नहीं है जब प्रक्रियाओं को स्वचालित और स्वचालित रूप से निष्पादित किया जा सकता है (उदाहरण के लिए, परीक्षण, निरंतर एकीकरण, निरंतर वितरण)।

कुछ सामान्य चुस्त विकास उपकरण (वे के रूप में बदल जाते हैं
सबसे अच्छी उपस्थिति):

• Git, ClearCase, या Subversion स्रोत कोड में परिवर्तन पर नज़र रखने के लिए एक संस्करण नियंत्रण प्रणाली है। आधुनिक विकास में Git वास्तविक मानक है।
• BitBucket या GitHub - रिपॉजिटरी की मेजबानी। यह टिकटों को भी ट्रैक करता है, उत्पादकता में सुधार के लिए निरंतर एकीकरण और अन्य उपकरणों के लिए "एप्लिकेशन" है। व्यापक रूप से खुले स्रोत समुदाय द्वारा उपयोग किया जाता है।
• जेनकिंस, सर्किल सीआई या ट्रैविस सीआई बिटकबेट और गिटहब परियोजनाओं के निर्माण और परीक्षण के लिए एक निरंतर एकीकरण सेवा है।
• शेफ, अन्सिबल या कठपुतली - कॉन्फ़िगरेशन और प्रसारण कार्यों के लिए "रेसिपी" बनाने और कई सर्वरों को सपोर्ट करने का सॉफ्टवेयर।
• डॉकर एक कंप्यूटर प्रोग्राम है जो ऑपरेटिंग सिस्टम स्तर पर वर्चुअलाइजेशन करता है, जिसे कंटेनरीकरण भी कहा जाता है।
• कंटेनर ऑर्केस्ट्रेशन के लिए कुबेरनेट्स या डॉकर झुंड।
• जीरा या निर्णायक ट्रैकर - टिकट, निगरानी और प्रबंधन।

ग्राफिक संस्करण:

डेवलपर्स के लिए प्रश्न

• आप कोड का परीक्षण कैसे करते हैं? (गलत जवाब: "हमारे पास परीक्षण के लिए एक विशेष संगठन है", "परीक्षण के लिए परीक्षण और उत्पाद मूल्यांकन विभाग जिम्मेदार है")
  
  • विस्तारित संस्करण: इकाई परीक्षण, प्रतिगमन परीक्षण, कार्यात्मक परीक्षण, सुरक्षा स्कैन, और परिनियोजन प्रमाणन के लिए आप किस उपकरण का उपयोग करते हैं?
• विकास, परीक्षण, सुरक्षा और तैनाती पाइपलाइन कितनी स्वचालित हैं?
  
  • विस्तारित संस्करण: निरंतर एकीकरण (CI), निरंतर वितरण (CD), प्रतिगमन परीक्षण, कार्यक्रम प्रलेखन के लिए आप किस उपकरण का उपयोग करते हैं; क्या आपका इन्फ्रास्ट्रक्चर कोड संचालित है?
• आपके उपयोगकर्ता कौन हैं और आप उनके साथ कैसे बातचीत करते हैं?
  
  • विस्तारित संस्करण: उपयोगकर्ताओं से प्रत्यक्ष प्रतिक्रिया प्राप्त करने के लिए आप किन तंत्रों का उपयोग करते हैं? बग रिपोर्ट बनाने और टिकट ट्रैक करने के लिए आप किस टूलसेट का उपयोग करते हैं? आप टीमों के बीच बग फिक्सिंग का काम कैसे वितरित करते हैं? आप उपयोगकर्ताओं को कैसे सूचित करते हैं कि उनके मुद्दों को हल किया जा रहा है और / या पहले से ही हल किया गया है?
• वर्तमान और भविष्य के रिलीज साइकिल की समय सीमा क्या है?
  
  • विस्तारित संस्करण: आप किस सॉफ़्टवेयर प्लेटफ़ॉर्म का समर्थन करते हैं? क्या आप कंटेनरों का उपयोग करते हैं? आपके कॉन्फ़िगरेशन प्रबंधन उपकरण क्या हैं?

परियोजना प्रबंधकों के लिए प्रश्न

• कितने प्रोग्रामर संगठन का हिस्सा हैं जो बजट आवंटित करते हैं, और कार्यक्रम के मुख्य चरण क्या हैं? (गलत उत्तर: "हम नहीं जानते", "शून्य", "यह एक प्रोग्रामर की परिभाषा पर निर्भर करता है")
• विकास और संचालन के लिए प्रबंधन मीट्रिक क्या हैं; प्राथमिकताओं को संप्रेषित करने, समस्याओं की पहचान करने के लिए उनका उपयोग कैसे किया जाता है; वे कितनी बार मैनुअल देखते हैं और उपयोग करते हैं?
• आपने पिछले तीन क्षेत्रों में क्या सीखा है और नए ज्ञान को कैसे लागू किया जाए? (गलत उत्तर: "स्प्रिंट क्या है?", "हम नेतृत्व के अनुमोदन की प्रतीक्षा कर रहे हैं")
• प्रत्येक स्प्रिंट चक्र से लाभ उठाने वाले उपयोगकर्ता कौन हैं? क्या मैं उनसे बात कर सकता हूं? (गलत उत्तर: "हम उपयोगकर्ताओं के लिए कोड को सीधे तैनात नहीं करते हैं")

ग्राहकों और उपयोगकर्ताओं के लिए प्रश्न

• आप डेवलपर्स के साथ कैसे संवाद करते हैं? क्या वे आपके काम की देखरेख करते हैं और प्रासंगिक प्रश्न पूछते हैं जो आपकी आवश्यकताओं की गहरी समझ का संकेत देते हैं? आखिरी बार जब वे पास बैठे थे और उन विशेषताओं पर चर्चा की थी जिन्हें आप देखना चाहते हैं?
• मैं नई सुविधाओं के लिए सुझाव कैसे प्रस्तुत करूं या कोड में समस्याओं या बगों की रिपोर्ट करूं? आपको अपनी पूछताछ / रिपोर्ट के लिए क्या प्रतिक्रिया मिलती है? क्या आपको कभी नई सॉफ़्टवेयर सुविधाओं के प्रोटोटाइप की कोशिश करने के लिए कहा गया है और यह देखा है कि आप उनका उपयोग कैसे करते हैं?
• आवेदन में अनुरोधित फ़ंक्शन को लागू करने में कितना समय लगता है?

मार्गदर्शन के लिए प्रश्न

• क्या सॉफ़्टवेयर का एक कार्यशील संस्करण प्रत्येक पुनरावृत्ति (पहले सहित) पर कम से कम वास्तविक उपयोगकर्ताओं का एक छोटा सा नमूना दिया गया है और क्या समीक्षाएँ एकत्र की गई हैं? (संकेत: हर दो सप्ताह)
• क्या कोई उत्पाद चार्टर है जो मिशन और रणनीतिक लक्ष्यों को निर्धारित करता है? क्या टीम के सभी सदस्य दोनों को समझते हैं? क्या वे देखते हैं कि उनका काम लक्ष्यों की प्राप्ति में कैसे योगदान देता है?
• क्या उपयोगकर्ता समीक्षाएं स्प्रिंट टीमों के लिए विशिष्ट कार्यों में एक महीने से कम समय सीमा के साथ बदल जाती हैं?
• क्या उपयोगकर्ता प्रतिक्रिया के आधार पर आवश्यकताओं को बदलने के लिए टीम को अधिकृत किया गया है?
• क्या टीमों को विकास के दौरान सीखी गई बातों के आधार पर अपनी प्रक्रिया को बदलने का अधिकार है?
• क्या आपकी परियोजना का पूरा पारिस्थितिकी तंत्र लचीला है? (यदि फुर्तीली विकास एक रैखिक, नौकरशाही कार्यान्वयन प्रक्रिया द्वारा पीछा किया जाता है, तो यह एक विफलता है।)

एजाइल टीमों के लिए, इन सभी सवालों का जवाब हां होना चाहिए।

ग्राफिक संस्करण:



रक्षा मंत्रालय के कार्यक्रमों के कुछ कार्यों के बारे में अधिक विस्तृत जानकारी परिशिष्ट A ( दस सॉफ्टवेयर आवश्यकताएँ ), परिशिष्ट B ( सॉफ्टवेयर विकास के लिए मेट्रिक्स ) और परिशिष्ट C (सॉफ्टवेयर त्रुटियां और नियम [लिंक बाद में जोड़ा जाएगा] में निहित है। )।