स्केल्ड एजाइल फ्रेमवर्क
| Part of a series on |
| Software development |
|---|
स्केल्ड एजाइल फ्रेमवर्क (एसएएफई) संगठन और वर्कफ़्लो पैटर्न का सेट है जिसका उद्देश्य नवाचारों के स्केलिंग लीन सॉफ्टवेयर विकास और एजाइल सॉफ्टवेयर विकास प्रथाओं में उद्यमों का मार्गदर्शन करना है।[1][2] अनुशासित चुस्त डिलीवरी (डीएडी) के साथ, एसएएफई उन बढ़ती संख्या में ढांचे में से है जो टीम से आगे बढ़ने पर आने वाली समस्याओं का समाधान करना चाहता है।[3][4] SAFe बड़ी संख्या में चुस्त टीमों के बीच संरेखण, सहयोग और वितरण को बढ़ावा देता है। इसे ज्ञान के तीन प्राथमिक निकायों का लाभ उठाकर अभ्यासकर्ताओं द्वारा और उनके लिए विकसित किया गया था: चुस्त सॉफ्टवेयर विकास, दुबला उत्पाद विकास और सिस्टम सोच।[5]
स्केल्ड एजाइल फ्रेमवर्क के लिए प्राथमिक संदर्भ मूल रूप से उत्पाद प्रबंधन (या अन्य परियोजना हितधारक) से परियोजना प्रशासन, कार्यक्रम प्रबंधन और सॉफ्टवेयर डेवलपर के माध्यम से ग्राहकों तक कैसे प्रवाहित होता है, इसकी बड़ी तस्वीर का विकास था।[6][7] फुर्तीले समुदाय के अन्य लोगों के सहयोग से, इसे उत्तरोत्तर परिष्कृत किया गया और फिर पहली बार 2007 की पुस्तक में औपचारिक रूप से वर्णित किया गया।[8] रूपरेखा का विकास और सार्वजनिक रूप से साझा किया जाना जारी है; अकादमी और मान्यता योजना के साथ उन लोगों का समर्थन करना जो SAFe को अपनाने में दूसरों को लागू करना, समर्थन करना या प्रशिक्षित करना चाहते हैं।
2011 में इसकी पहली रिलीज से शुरू होकर, छह प्रमुख संस्करण जारी किए गए हैं[9] जबकि नवीनतम संस्करण, संस्करण 6.0, मार्च 2023 में जारी किया गया था।[10] जबकि एसएएफई को चुस्त प्रथाओं को बढ़ाने के लिए सबसे आम दृष्टिकोण के रूप में पहचाना जा रहा है (30 प्रतिशत और बढ़ रहा है),[11][12],[13] इसे अत्यधिक पदानुक्रमित और अनम्य होने के कारण आलोचना भी मिली है।[14] परिचित प्रक्रियाओं को बरकरार रखते हुए संगठनों को एजाइल सॉफ्टवेयर विकास को अपनाने का भ्रम देने के लिए भी इसकी आलोचना होती है।[15]
चुस्त सिद्धांतों और प्रथाओं को बढ़ाने की चुनौतियाँ
लंबी योजना क्षितिज का सामना करना
विकास टीमें आमतौर पर अपने बैकलॉग को दो से तीन पुनरावृत्तियों तक परिष्कृत करती हैं, लेकिन बड़े संगठनों में उत्पाद विपणन टीम को बाजार के प्रति अपनी प्रतिबद्धताओं और ग्राहकों के साथ चर्चा के लिए आगे की योजना बनाने की आवश्यकता होती है।[16] वे अक्सर बहुत उच्च स्तर, 12 से 18 महीने के रोडमैप के साथ काम करेंगे, फिर तीन महीने के काम के लिए टीमों के साथ मिलकर योजना बनाएंगे। विकास टीमें अभी भी 2-3 पुनरावृत्तियों में विस्तृत परिशोधन में लगेंगी, केवल अगले पुनरावृत्ति के लिए विस्तृत कार्य योजनाओं में लगेंगी।
जिम्मेदारी के अमूर्त स्तरों पर चुस्त रहना
हालाँकि विकास टीमों के पास कई ढाँचे हैं जो परिभाषित करते हैं कि उन्हें कैसे चुस्त होना चाहिए, लेकिन प्रबंधन के लिए इसका वर्णन करने वाली बहुत कम है। SAFe उन समूहों को कई समान सिद्धांत प्रदान करता है, जैसे क्रॉस-फ़ंक्शनल टीम, जो जिम्मेदारी और योजना (उत्पाद और पोर्टफोलियो) के अधिक अमूर्त स्तरों को संभालते हैं।
प्रत्यायोजित प्राधिकार से निपटना
स्क्रम (सॉफ्टवेयर विकास) में, उत्पाद स्वामी से संपूर्ण उत्पाद जीवनचक्र|उत्पाद जीवनचक्र की जिम्मेदारी लेने की अपेक्षा की जाती है, जिसमें विकास निर्णयों के निवेश पर रिटर्न, साथ ही बाजार में प्रदर्शन भी शामिल है। बड़े पैमाने पर विकास पर, संगठन कई टीम बैकलॉग पर दृश्य चाहता है, जैसे कि उत्पाद प्रबंधक द्वारा प्रदान किया गया।[17] हालाँकि SAFe मानता है कि उत्पाद स्वामी की भूमिका उत्पाद प्रबंधन के साथ बैठती है, फिर भी उत्पाद मालिकों को विकास संगठन में अलग करने के लिए इसकी आलोचना की गई है।[18]
डिलिवरेबल्स को सिंक्रनाइज़ करना
एजाइल फ्रेमवर्क को विकास टीम को स्वायत्त बनाने और अपने काम करने के तरीके को डिजाइन करने के लिए स्वतंत्र बनाने के लिए डिज़ाइन किया गया है। SAFe स्वीकार करता है कि, कई दसियों या सैकड़ों विकास टीमों के पैमाने पर, टीमों के लिए पूरी तरह से आत्म-संगठित होना तेजी से अराजक हो जाता है।[19] इसलिए यह इस पर कुछ बाधाएँ डालता है, ताकि जहाँ टीमें ही उत्पाद पर काम कर रही हों, उनकी डिलिवरेबल्स को साथ जारी करने के लिए बेहतर ढंग से सिंक्रनाइज़ किया जा सके, हालाँकि यह ऐसा क्षेत्र रहा है जिसमें SAFe की आलोचना की गई है।[17][18]
नवप्रवर्तन और योजना के लिए समय देना
SAFe योजना चक्र रिलीज के बाद अतिरिक्त पुनरावृत्ति को शामिल करने की सिफारिश करता है, जिससे टीमों को अपनी प्रथाओं में सुधार करने और अगली योजना वृद्धि के लिए तैयार होने की अनुमति मिलती है। SAFe के पहले संस्करणों ने भी इसे सख्त पुनरावृत्ति के रूप में डिज़ाइन किया था, अर्थात् उत्पाद को जारी करने से पहले उसे स्थिर या कठोर करने के लिए। यह बड़े एकीकरण परिवेशों के साथ काम करने की जटिलताओं पर आधारित था जहां निर्भरताएं कई मामलों को अंत तक परीक्षण करने से रोकती थीं। SAFe की इसके लिए आलोचना की गई क्योंकि यह एंटी-एजाइल या वॉटरफॉल तत्व का प्रतिनिधित्व करता था, लेकिन यह 90-दिन की वेतन वृद्धि के अनुरूप था जो 13 सप्ताह बनाता है, और यदि दो सप्ताह की स्प्रिंट करते हैं तो आपको उनमें से छह की आवश्यकता होती है और साथ ही सप्ताह की योजना या सख्त होने का चक्र.[20] यह SAFe के हाल के संस्करणों में शामिल नहीं है।
कार्यान्वयन
SAFe के अंतर्निहित सिद्धांत
इसके लेखकों के अनुसार, SAFe दस अंतर्निहित अवधारणाओं पर आधारित है, जो मौजूदा दुबले और फुर्तीले सिद्धांतों के साथ-साथ अवलोकन से ली गई हैं:[21]
- आर्थिक दृष्टिकोण अपनाएं
- सिस्टम सोच लागू करें
- परिवर्तनशीलता मान लें; विकल्प सुरक्षित रखें
- तेजी से एकीकृत शिक्षण चक्रों के साथ वृद्धिशील रूप से निर्माण करें
- कार्य प्रणालियों के वस्तुनिष्ठ मूल्यांकन पर आधार मील के पत्थर
- चल रहे कार्य की कल्पना करें और उसे सीमित करें, बैच आकार कम करें, और कतार की लंबाई प्रबंधित करें
- ताल (समय) लागू करें, क्रॉस-डोमेन योजना के साथ सिंक्रनाइज़ करें
- ज्ञान कार्यकर्ताओं की आंतरिक प्रेरणा को अनलॉक करें
- विकेंद्रीकरण निर्णय लेना
- मूल्य के आसपास व्यवस्थित करें
बहुत सी असमान प्रथाओं को एकत्रित करने के लिए SAFe की आलोचना की गई है।[22]
SAFe ढांचा
SAFe संस्करण 5.1 में, चार कॉन्फ़िगरेशन हैं: आवश्यक, पोर्टफोलियो, बड़ा समाधान और पूर्ण:[23]
- एसेंशियल सेफ सबसे बुनियादी कॉन्फ़िगरेशन है। यह आवश्यक सबसे महत्वपूर्ण तत्वों का वर्णन करता है और इसका उद्देश्य ढांचे के अधिकांश लाभ प्रदान करना है। इसमें टीम और प्रोग्राम स्तर (जिसे वह एजाइल रिलीज़ ट्रेन या एआरटी कहते हैं) शामिल हैं।
- बड़ा समाधान SAFe कई कार्यक्रमों में समन्वय और सिंक्रनाइज़ेशन की अनुमति देता है, लेकिन पोर्टफोलियो पर विचार किए बिना। SAFe के पुराने संस्करणों में, इस स्तर को मूल्य धारा के रूप में संदर्भित किया गया था।
- पोर्टफोलियो SAFe में रणनीतिक दिशा, निवेश फंडिंग और लीन गवर्नेंस की चिंताएं शामिल हैं।
- पूर्ण SAFe अन्य तीन स्तरों को जोड़ती है।
प्रमाणपत्र
स्केल्ड एजाइल व्यावसायिक प्रमाणन (कंप्यूटर प्रौद्योगिकी) प्रदान करता है जो विभिन्न क्षेत्रों और ज्ञान स्तरों को कवर करता है।[24]
यह भी देखें
- स्क्रम (सॉफ़्टवेयर डेवलपमेंट)#स्क्रम ऑफ़ स्क्रम
संदर्भ
- ↑ Hayes, Will; Lapham, Mary Ann; Miller, Suzanne; Wrubel, Eileen; Capell, Peter (2016). रक्षा कार्यक्रम विभाग के लिए स्केलिंग एजाइल तरीके. Software Engineering Institute. CMU/SEI-2016-TN-005.
- ↑ Athrow, Desiree (29 January 2015). "सॉफ्टवेयर विकास को गति देने के लिए सतत वितरण महत्वपूर्ण क्यों है?". TechRadar. Retrieved 2017-11-27.
- ↑ Linders, Ben (January 22, 2015). "अनुशासित फुर्तीली डिलिवरी फ्रेमवर्क के साथ चुस्त गति को बढ़ाना". InfoQ. Retrieved 2017-11-27.
- ↑ van Haaster, K (2014). Agile in-the-large: Getting from Paradox to Paradigm. Unpublished paper from Charles Sturt University.
- ↑ King, Michael (2017). "SAFe अवधारणाओं के साथ संघीय ग्राहकों को सेवा प्रदान करना" (PDF). Capability Counts Conference Proceedings.[dead link]
- ↑ Bridgwater, Adrian (August 7, 2013). "रियल एजाइल का मतलब है हर कोई फुर्तीला है". Dr. Dobb's. Retrieved 2017-11-27.
- ↑ Linders, Ben (August 28, 2014). "एजाइल एडॉप्शन में योजना द्वारा मृत्यु". InfoQ. Retrieved 2017-11-27.
- ↑ Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. ISBN 978-0321458193.
- ↑ "स्केल्ड एजाइल फ्रेमवर्क के बारे में - SAFe का संक्षिप्त इतिहास". Scaled Agile Inc. Retrieved 12 August 2020.
- ↑ "Say Hello to SAFE 6.0". Scaled Agile Inc. Retrieved 2023-03-16.
- ↑ "13th Annual State of Agile Report". State of Agile Survey. CollabNet VersionOne. 2019. Retrieved 2019-08-27.
- ↑ Link, P; Lewrick, M (29 September 2014). "नवप्रवर्तन प्रबंधन के एक नए क्षेत्र में चुस्त तरीके" (PDF). Science to Business Marketing Conference.
- ↑ Baptista, Roberto (28 January 2015). "Profissionais brasileiros e o interesse por treinamentos de especialização". Computerworld Brazil. Retrieved 28 January 2015.
- ↑ Schwaber, Ken (2013-08-06). "किसी भी गति से असुरक्षित". Telling It Like It Is. Retrieved 2017-11-11.
- ↑ Gothelf, Jeff (2021-10-05). "SAFe चुस्त नहीं है". Retrieved 2023-05-21.
- ↑ Eklund, U; Olsson, H; Strøm, N (2014). बड़े पैमाने पर उत्पादित एम्बेडेड सिस्टम में चुस्तता बढ़ाने की औद्योगिक चुनौतियाँ।. ISBN 9783319143583.
{{cite book}}:|work=ignored (help) - ↑ 17.0 17.1 Vaidya, A (2014). Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise. Excerpt from PNSQC 2014 Proceedings. pp. 8–9.
- ↑ 18.0 18.1 Maximini, Dominik (11 September 2013). "SAFe - स्क्रुमोराकेल - ब्लॉग पर एक आलोचनात्मक दृष्टिकोण". Scrum Oracle. Retrieved 2017-11-27.
- ↑ Stafford, Jan (December 9, 2013). "सलाहकार का कहना है कि स्केलिंग एजाइल विकास के लिए परिभाषित प्रथाओं की आवश्यकता होती है". SearchSoftwareQuality. Retrieved 2017-11-27.[dead link]
- ↑ Killick, Neil (21 March 2012). "स्केल्ड एजाइल फ्रेमवर्क की भयावहता". Agile, Scrum, Kanban, Lean, and everything that's in between. Retrieved 2017-11-27.
- ↑ "सुरक्षित लीन-एजाइल सिद्धांत". Retrieved 19 February 2016.
- ↑ Elssamadisy, Amr. "Has SAFe Cracked the Large Agile Adoption Nut?". InfoQ. Retrieved 2017-11-11.
- ↑ Rose, Doug (2018). डमीज़ के लिए उद्यम चपलता (in English). John Wiley & Sons. pp. 87–89. ISBN 9781119446095.
- ↑ "प्रमाणीकरण". Scaled Agile. Retrieved 19 February 2016.
अग्रिम पठन
- Dingsøyr, Torgeir; Falessi, David; Power, Ken (February 2019), "Agile Development at Scale: The Next Frontier", IEEE Software, 36 (2): 30–38, doi:10.1109/MS.2018.2884884, S2CID 57373760
- Heusser, Matthew (17 June 2015), Introducing the scaled agile framework, CIO, pp. 1–2 — contains a review of the pros and cons of the methodology and concludes it is a half-way-house to a fully agile system.
- Leffingwell, Dean (2011), Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley Professional, ISBN 978-0321635846
- Linders, Ben (15 January 2015), Lean and Agile Leadership with the Scaled Agile Framework (SAFe), InfoQ
