स्केल्ड एजाइल फ्रेमवर्क

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

2011 में इसकी पहली रिलीज से शुरू होकर, छह प्रमुख संस्करण जारी किए गए हैं जबकि नवीनतम संस्करण, संस्करण 6.0, मार्च 2023 में जारी किया गया था। जबकि एसएएफई को चुस्त प्रथाओं को बढ़ाने के लिए सबसे आम दृष्टिकोण के रूप में पहचाना जा रहा है (30 प्रतिशत और बढ़ रहा है),, इसे अत्यधिक पदानुक्रमित और अनम्य होने के कारण आलोचना भी मिली है। परिचित प्रक्रियाओं को बरकरार रखते हुए संगठनों को एजाइल सॉफ्टवेयर विकास को अपनाने का भ्रम देने के लिए भी इसकी आलोचना होती है।

लंबी योजना क्षितिज का सामना करना
विकास टीमें आमतौर पर अपने बैकलॉग को दो से तीन पुनरावृत्तियों तक परिष्कृत करती हैं, लेकिन बड़े संगठनों में उत्पाद विपणन टीम को बाजार के प्रति अपनी प्रतिबद्धताओं और ग्राहकों के साथ चर्चा के लिए आगे की योजना बनाने की आवश्यकता होती है। वे अक्सर बहुत उच्च स्तर, 12 से 18 महीने के रोडमैप के साथ काम करेंगे, फिर तीन महीने के काम के लिए टीमों के साथ मिलकर योजना बनाएंगे। विकास टीमें अभी भी 2-3 पुनरावृत्तियों में विस्तृत परिशोधन में लगेंगी, केवल अगले पुनरावृत्ति के लिए विस्तृत कार्य योजनाओं में लगेंगी।

जिम्मेदारी के अमूर्त स्तरों पर चुस्त रहना
हालाँकि विकास टीमों के पास कई ढाँचे हैं जो परिभाषित करते हैं कि उन्हें कैसे चुस्त होना चाहिए, लेकिन प्रबंधन के लिए इसका वर्णन करने वाली बहुत कम है। SAFe उन समूहों को कई समान सिद्धांत प्रदान करता है, जैसे क्रॉस-फ़ंक्शनल टीम, जो जिम्मेदारी और योजना (उत्पाद और पोर्टफोलियो) के अधिक अमूर्त स्तरों को संभालते हैं।

प्रत्यायोजित प्राधिकार से निपटना
स्क्रम (सॉफ्टवेयर विकास) में, उत्पाद स्वामी से संपूर्ण उत्पाद जीवनचक्र|उत्पाद जीवनचक्र की जिम्मेदारी लेने की अपेक्षा की जाती है, जिसमें विकास निर्णयों के निवेश पर रिटर्न, साथ ही बाजार में प्रदर्शन भी शामिल है। बड़े पैमाने पर विकास पर, संगठन कई टीम बैकलॉग पर एक दृश्य चाहता है, जैसे कि उत्पाद प्रबंधक द्वारा प्रदान किया गया। हालाँकि SAFe मानता है कि उत्पाद स्वामी की भूमिका उत्पाद प्रबंधन के साथ बैठती है, फिर भी उत्पाद मालिकों को विकास संगठन में अलग करने के लिए इसकी आलोचना की गई है।

डिलिवरेबल्स को सिंक्रनाइज़ करना
एजाइल फ्रेमवर्क को विकास टीम को स्वायत्त बनाने और अपने काम करने के तरीके को डिजाइन करने के लिए स्वतंत्र बनाने के लिए डिज़ाइन किया गया है। SAFe स्वीकार करता है कि, कई दसियों या सैकड़ों विकास टीमों के पैमाने पर, टीमों के लिए पूरी तरह से आत्म-संगठित होना तेजी से अराजक हो जाता है। इसलिए यह इस पर कुछ बाधाएँ डालता है, ताकि जहाँ टीमें एक ही उत्पाद पर काम कर रही हों, उनकी डिलिवरेबल्स को एक साथ जारी करने के लिए बेहतर ढंग से सिंक्रनाइज़ किया जा सके, हालाँकि यह एक ऐसा क्षेत्र रहा है जिसमें SAFe की आलोचना की गई है।

नवप्रवर्तन और योजना के लिए समय देना
SAFe योजना चक्र एक रिलीज के बाद एक अतिरिक्त पुनरावृत्ति को शामिल करने की सिफारिश करता है, जिससे टीमों को अपनी प्रथाओं में सुधार करने और अगली योजना वृद्धि के लिए तैयार होने की अनुमति मिलती है। SAFe के पहले संस्करणों ने भी इसे एक सख्त पुनरावृत्ति के रूप में डिज़ाइन किया था, अर्थात् उत्पाद को जारी करने से पहले उसे स्थिर या कठोर करने के लिए। यह बड़े एकीकरण परिवेशों के साथ काम करने की जटिलताओं पर आधारित था जहां निर्भरताएं कई मामलों को अंत तक परीक्षण करने से रोकती थीं। SAFe की इसके लिए आलोचना की गई क्योंकि यह एक एंटी-एजाइल या वॉटरफॉल तत्व का प्रतिनिधित्व करता था, लेकिन यह 90-दिन की वेतन वृद्धि के अनुरूप था जो 13 सप्ताह बनाता है, और यदि दो सप्ताह की स्प्रिंट करते हैं तो आपको उनमें से छह की आवश्यकता होती है और साथ ही एक सप्ताह की योजना या सख्त होने का चक्र. यह SAFe के हाल के संस्करणों में शामिल नहीं है।

SAFe के अंतर्निहित सिद्धांत
इसके लेखकों के अनुसार, SAFe दस अंतर्निहित अवधारणाओं पर आधारित है, जो मौजूदा दुबले और फुर्तीले सिद्धांतों के साथ-साथ अवलोकन से ली गई हैं:
 * 1) आर्थिक दृष्टिकोण अपनाएं
 * 2) सिस्टम सोच लागू करें
 * 3) परिवर्तनशीलता मान लें; विकल्प सुरक्षित रखें
 * 4) तेजी से एकीकृत शिक्षण चक्रों के साथ वृद्धिशील रूप से निर्माण करें
 * 5) कार्य प्रणालियों के वस्तुनिष्ठ मूल्यांकन पर आधार मील के पत्थर
 * 6) चल रहे कार्य की कल्पना करें और उसे सीमित करें, बैच आकार कम करें, और कतार की लंबाई प्रबंधित करें
 * 7) ताल (समय) लागू करें, क्रॉस-डोमेन योजना के साथ सिंक्रनाइज़ करें
 * 8) ज्ञान कार्यकर्ताओं की आंतरिक प्रेरणा को अनलॉक करें
 * 9) विकेंद्रीकरण निर्णय लेना
 * 10) मूल्य के आसपास व्यवस्थित करें

बहुत सी असमान प्रथाओं को एकत्रित करने के लिए SAFe की आलोचना की गई है।

SAFe ढांचा
SAFe संस्करण 5.1 में, चार कॉन्फ़िगरेशन हैं: आवश्यक, पोर्टफोलियो, बड़ा समाधान और पूर्ण:
 * एसेंशियल सेफ सबसे बुनियादी कॉन्फ़िगरेशन है। यह आवश्यक सबसे महत्वपूर्ण तत्वों का वर्णन करता है और इसका उद्देश्य ढांचे के अधिकांश लाभ प्रदान करना है। इसमें टीम और प्रोग्राम स्तर (जिसे वह एजाइल रिलीज़ ट्रेन या एआरटी कहते हैं) शामिल हैं।
 * बड़ा समाधान SAFe कई कार्यक्रमों में समन्वय और सिंक्रनाइज़ेशन की अनुमति देता है, लेकिन पोर्टफोलियो पर विचार किए बिना। SAFe के पुराने संस्करणों में, इस स्तर को मूल्य धारा  के रूप में संदर्भित किया गया था।
 * पोर्टफोलियो SAFe में रणनीतिक दिशा, निवेश फंडिंग और लीन गवर्नेंस की चिंताएं शामिल हैं।
 * पूर्ण SAFe अन्य तीन स्तरों को जोड़ती है।

प्रमाणपत्र
स्केल्ड एजाइल व्यावसायिक प्रमाणन (कंप्यूटर प्रौद्योगिकी) प्रदान करता है जो विभिन्न क्षेत्रों और ज्ञान स्तरों को कवर करता है।

यह भी देखें

 * स्क्रम (सॉफ़्टवेयर डेवलपमेंट)#स्क्रम ऑफ़ स्क्रम

अग्रिम पठन

 * — contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.
 * — contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.