स्केल्ड एजाइल फ्रेमवर्क: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Software development process}} | {{Software development process}} | ||
{{Short description|Set of workflow practices}} | {{Short description|Set of workflow practices}} | ||
'''स्केल्ड एजाइल फ्रेमवर्क''' (एसएएफई) संगठन और वर्कफ़्लो पैटर्न का सेट होता है जिसका उद्देश्य नवाचारों के स्केलिंग [[लीन सॉफ्टवेयर विकास]] और एजाइल सॉफ्टवेयर विकास प्रथाओं में उद्यमों का मार्गदर्शन करना है।<ref>{{Cite book|title=रक्षा कार्यक्रम विभाग के लिए स्केलिंग एजाइल तरीके|last1=Hayes|first1=Will|last2=Lapham|first2=Mary Ann|last3=Miller|first3=Suzanne|last4=Wrubel|first4=Eileen|last5=Capell|first5=Peter|publisher=Software Engineering Institute|year=2016|id=CMU/SEI-2016-TN-005}}</ref><ref>{{Cite news|url=http://www.techradar.com/news/software/why-continuous-delivery-is-key-to-speeding-up-software-development-1282498|title=सॉफ्टवेयर विकास को गति देने के लिए सतत वितरण महत्वपूर्ण क्यों है?|last=Athrow|first=Desiree|date=29 January 2015|work=TechRadar|access-date=2017-11-27}}</ref> और अनुशासित तीव्र डिलीवरी (डीएडी) के साथ, एसएएफई उन बढ़ती संख्या में रूपरेखा में से है | '''स्केल्ड एजाइल फ्रेमवर्क''' (एसएएफई) संगठन और वर्कफ़्लो पैटर्न का सेट होता है जिसका उद्देश्य नवाचारों के स्केलिंग [[लीन सॉफ्टवेयर विकास]] और एजाइल सॉफ्टवेयर विकास प्रथाओं में उद्यमों का मार्गदर्शन करना है।<ref>{{Cite book|title=रक्षा कार्यक्रम विभाग के लिए स्केलिंग एजाइल तरीके|last1=Hayes|first1=Will|last2=Lapham|first2=Mary Ann|last3=Miller|first3=Suzanne|last4=Wrubel|first4=Eileen|last5=Capell|first5=Peter|publisher=Software Engineering Institute|year=2016|id=CMU/SEI-2016-TN-005}}</ref><ref>{{Cite news|url=http://www.techradar.com/news/software/why-continuous-delivery-is-key-to-speeding-up-software-development-1282498|title=सॉफ्टवेयर विकास को गति देने के लिए सतत वितरण महत्वपूर्ण क्यों है?|last=Athrow|first=Desiree|date=29 January 2015|work=TechRadar|access-date=2017-11-27}}</ref> और अनुशासित तीव्र डिलीवरी (डीएडी) के साथ, एसएएफई उन बढ़ती संख्या में रूपरेखा में से है जो की टीम से आगे बढ़ने पर आने वाली समस्याओं का समाधान करना चाहता है।<ref>{{Cite web|url=https://www.infoq.com/news/2015/01/disciplined-agile-delivery|title=अनुशासित फुर्तीली डिलिवरी फ्रेमवर्क के साथ चुस्त गति को बढ़ाना|last=Linders|first=Ben|date=January 22, 2015|website=InfoQ|access-date=2017-11-27}}</ref><ref>{{Cite book|title=Agile in-the-large: Getting from Paradox to Paradigm|last=van Haaster|first=K|publisher=Unpublished paper from Charles Sturt University|year=2014}}</ref> | ||
इस प्रकार से स्केल्ड एजाइल फ्रेमवर्क के लिए प्राथमिक संदर्भ मूल रूप से [[उत्पाद प्रबंधन]] (या अन्य [[परियोजना हितधारक]]) से [[परियोजना प्रशासन]], [[कार्यक्रम प्रबंधन]] और [[सॉफ्टवेयर डेवलपर]] के माध्यम से [[ग्राहक]] | एसएएफई बड़ी संख्या में चुस्त टीमों के बीच संरेखण, सहयोग और वितरण को बढ़ावा देता है। इसे ज्ञान, तीव्र सॉफ्टवेयर विकास, दुबले उत्पाद विकास और सिस्टम सोच के तीन प्राथमिक निकायों का लाभ उठाकर, चिकित्सकों द्वारा और उनके लिए विकसित किया गया था।<ref>{{Cite journal|last=King|first=Michael|year=2017|title=SAFe अवधारणाओं के साथ संघीय ग्राहकों को सेवा प्रदान करना|url=http://cmmiinstitute.com/sites/default/files/resource_asset/Serving%20Federal%20Customers%20Using%20Agile%2C%20SAFe%2C%20And%20CMMI%20Principles.pdf|journal=Capability Counts Conference Proceedings}}{{dead link|date=September 2022}} </ref> | ||
इस प्रकार से स्केल्ड एजाइल फ्रेमवर्क के लिए प्राथमिक संदर्भ मूल रूप से [[उत्पाद प्रबंधन]] (या अन्य [[परियोजना हितधारक]]) से [[परियोजना प्रशासन]], [[कार्यक्रम प्रबंधन]] और [[सॉफ्टवेयर डेवलपर]] के माध्यम से [[ग्राहक]] तक कैसे प्रवाहित होता है, इसकी बड़ी तस्वीर का विकास था।<ref>{{Cite news|url=http://www.drdobbs.com/tools/real-agile-means-everybody-is-agile/240159622|title=रियल एजाइल का मतलब है हर कोई फुर्तीला है|last=Bridgwater|first=Adrian|date=August 7, 2013|work=Dr. Dobb's|access-date=2017-11-27}}</ref><ref>{{Cite web|url=https://www.infoq.com/news/2014/08/death-by-planning-agile|title=एजाइल एडॉप्शन में योजना द्वारा मृत्यु|last=Linders|first=Ben|date=August 28, 2014|website=InfoQ|access-date=2017-11-27}}</ref> तीव्र समुदाय के अन्य लोगों के सहयोग से, इसे उत्तरोत्तर परिष्कृत किया गया और फिर पहली बार 2007 की पुस्तक में औपचारिक रूप से वर्णित किया गया।<ref>{{Cite book|title=Scaling Software Agility: Best Practices for Large Enterprises|last=Leffingwell|first=Dean|publisher=Addison-Wesley|year=2007|isbn=978-0321458193}}</ref> रूपरेखा का विकास और सार्वजनिक रूप से साझा किया जाना प्रवाहित है; अकादमी और मान्यता योजना के साथ उन लोगों का समर्थन करना जो एसएएफई को अपनाने में दूसरों को प्रयुक्त करना है ,और समर्थन करना या प्रशिक्षित करना चाहते हैं। | |||
इस प्रकार से 2011 में इसकी प्रथम रिलीज से प्रारंभ होकर, छह प्रमुख संस्करण प्रवाहित किए गए हैं<ref name="History of SAFe">{{cite web |title=स्केल्ड एजाइल फ्रेमवर्क के बारे में - SAFe का संक्षिप्त इतिहास|url=https://www.scaledagileframework.com/about/ |publisher=Scaled Agile Inc. |access-date=12 August 2020}}</ref> जबकि नवीनतम संस्करण, संस्करण 6.0, मार्च 2023 में प्रवाहित किया गया था।<ref>{{Cite web|url=https://scaledagileframework.com/blog/say-hello-to-safe-6-0/|title=Say Hello to SAFE 6.0|publisher=Scaled Agile Inc|access-date=2023-03-16}}</ref> | इस प्रकार से 2011 में इसकी प्रथम रिलीज से प्रारंभ होकर, छह प्रमुख संस्करण प्रवाहित किए गए हैं<ref name="History of SAFe">{{cite web |title=स्केल्ड एजाइल फ्रेमवर्क के बारे में - SAFe का संक्षिप्त इतिहास|url=https://www.scaledagileframework.com/about/ |publisher=Scaled Agile Inc. |access-date=12 August 2020}}</ref> जबकि नवीनतम संस्करण, संस्करण 6.0, मार्च 2023 में प्रवाहित किया गया था।<ref>{{Cite web|url=https://scaledagileframework.com/blog/say-hello-to-safe-6-0/|title=Say Hello to SAFE 6.0|publisher=Scaled Agile Inc|access-date=2023-03-16}}</ref> | ||
| Line 15: | Line 17: | ||
===उत्तरदायित्व के अमूर्त स्तरों पर तीव्र बने रहना === | ===उत्तरदायित्व के अमूर्त स्तरों पर तीव्र बने रहना === | ||
चूंकि विकास टीमों के पास कई फ़्रेमवर्क हैं | चूंकि विकास टीमों के पास कई फ़्रेमवर्क हैं जो की परिभाषित करते हैं कि उन्हें कैसे तीव्र होना चाहिए, किन्तु प्रबंधन के लिए इसका वर्णन करने वाली अधिक कम होती है। और एसएएफई उन समूहों को कई समान सिद्धांत प्रदान करता है, जैसे क्रॉस-फ़ंक्शनल टीम, जो उत्तरदायी और योजना (उत्पाद और पोर्टफोलियो) के अधिक अमूर्त स्तरों को संभालते हैं। | ||
=== प्रत्यायोजित प्राधिकार के साथ व्यवहार === | === प्रत्यायोजित प्राधिकार के साथ व्यवहार === | ||
इस प्रकार से स्क्रम (सॉफ्टवेयर विकास) में, उत्पाद स्वामी से संपूर्ण उत्पाद जीवनचक्र उत्पाद जीवनचक्र की उत्तरदायी लेने की अपेक्षा की जाती है, जिसमें विकास निर्णयों के निवेश पर रिटर्न, साथ ही बाजार में प्रदर्शन भी सम्मिलित होते है। और उच्च माप पर विकास पर, संगठन कई टीम बैकलॉग पर दृश्य चाहता है, जैसे कि [[उत्पाद प्रबंधक]] द्वारा प्रदान किया गया था ।<ref name=":2">{{Cite book|title=Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise|last=Vaidya|first=A|publisher=Excerpt from PNSQC 2014 Proceedings|year=2014|pages=8–9}}</ref> चूंकि एसएएफई मानता है कि उत्पाद स्वामी की भूमिका उत्पाद प्रबंधन के साथ बैठती है, फिर भी उत्पाद मालिकों को विकास संगठन में अलग करने के लिए इसकी आलोचना की गई है।<ref name=":3">{{Cite web|url=http://scrumorakel.de/blog/index.php?/archives/45-A-critical-view-on-SAFe.html|title=SAFe - स्क्रुमोराकेल - ब्लॉग पर एक आलोचनात्मक दृष्टिकोण|last=Maximini|first=Dominik|date=11 September 2013|website=Scrum Oracle|access-date=2017-11-27}}</ref> | इस प्रकार से स्क्रम (सॉफ्टवेयर विकास) में, उत्पाद स्वामी से संपूर्ण उत्पाद जीवनचक्र उत्पाद जीवनचक्र की उत्तरदायी लेने की अपेक्षा की जाती है, जिसमें विकास निर्णयों के निवेश पर रिटर्न, साथ ही बाजार में प्रदर्शन भी सम्मिलित होते है। और उच्च माप पर विकास पर, संगठन कई टीम बैकलॉग पर दृश्य चाहता है, जैसे कि [[उत्पाद प्रबंधक]] द्वारा प्रदान किया गया था ।<ref name=":2">{{Cite book|title=Does DAD Know Best, Is it Better to do LeSS or Just be SAFe? Adapting Scaling Agile Practices into the Enterprise|last=Vaidya|first=A|publisher=Excerpt from PNSQC 2014 Proceedings|year=2014|pages=8–9}}</ref> चूंकि एसएएफई मानता है कि उत्पाद स्वामी की भूमिका उत्पाद प्रबंधन के साथ बैठती है, फिर भी उत्पाद मालिकों को विकास संगठन में अलग करने के लिए इसकी आलोचना की गई है।<ref name=":3">{{Cite web|url=http://scrumorakel.de/blog/index.php?/archives/45-A-critical-view-on-SAFe.html|title=SAFe - स्क्रुमोराकेल - ब्लॉग पर एक आलोचनात्मक दृष्टिकोण|last=Maximini|first=Dominik|date=11 September 2013|website=Scrum Oracle|access-date=2017-11-27}}</ref> | ||
=== डिलिवरेबल्स को सिंक्रनाइज़ करना === | === डिलिवरेबल्स को सिंक्रनाइज़ करना === | ||
एजाइल फ्रेमवर्क को विकास टीम को स्वायत्त बनाने और अपने कार्य करने के विधि को डिजाइन करने के लिए स्वतंत्र बनाने के लिए डिज़ाइन किया गया है। चूंकि एसएएफई स्वीकार करता है कि | एजाइल फ्रेमवर्क को विकास टीम को स्वायत्त बनाने और अपने कार्य करने के विधि को डिजाइन करने के लिए स्वतंत्र बनाने के लिए डिज़ाइन किया गया है। चूंकि एसएएफई स्वीकार करता है कि कई दसियों या सैकड़ों विकास टीमों के माप पर, टीमों के लिए पूर्ण रूप से आत्म-संगठित होना तीव्र से अराजक हो जाता है।<ref name=":1">{{Cite news|url=http://searchsoftwarequality.techtarget.com/answer/Scaling-Agile-development-calls-for-defined-practices-consultant-says|title=सलाहकार का कहना है कि स्केलिंग एजाइल विकास के लिए परिभाषित प्रथाओं की आवश्यकता होती है|last=Stafford|first=Jan|date=December 9, 2013|work=SearchSoftwareQuality|access-date=2017-11-27}}{{dead link|date=September 2022}}</ref> इसलिए यह इस पर कुछ बाधाएँ होती है, जिससे जहाँ टीमें ही उत्पाद पर कार्य कर रही हों, उनकी डिलिवरेबल्स को साथ प्रवाहित करने के लिए ठीक प्रकार से सिंक्रनाइज़ किया जा सकता है, चूंकि यह ऐसा क्षेत्र रहा है जिसमें एसएएफई की आलोचना की गई है।<ref name=":2" /><ref name=":3" /> | ||
=== नवप्रवर्तन और योजना के लिए समय देना === | === नवप्रवर्तन और योजना के लिए समय देना === | ||
इस प्रकार से एसएएफई योजना चक्र रिलीज के बाद अतिरिक्त पुनरावृत्ति को सम्मिलित करने की अनुशंसा करता है, जिससे टीमों को अपनी प्रथाओं में सुधार करने और अगली योजना वृद्धि के लिए तैयार होने की अनुमति मिलती है। और एसएएफई के प्रथम संस्करणों ने भी इसे जटिल पुनरावृत्ति के रूप में डिज़ाइन किया था, अर्थात् उत्पाद को प्रवाहित करने से पहले उसे स्थिर या कठोर करने के लिए किया जाता है । यह उच्च एकीकरण परिवेशों के साथ कार्य करने की जटिलताओं पर आधारित था जहां निर्भरताएं कई स्तिथियों को अंत तक परीक्षण करने से रोकती थीं। एसएएफई की इसके लिए आलोचना की गई क्योंकि यह एंटी-एजाइल या वॉटरफॉल तत्व का प्रतिनिधित्व करता था, किन्तु यह 90-दिन की वेतन वृद्धि के अनुरूप था | इस प्रकार से एसएएफई योजना चक्र रिलीज के बाद अतिरिक्त पुनरावृत्ति को सम्मिलित करने की अनुशंसा करता है, जिससे टीमों को अपनी प्रथाओं में सुधार करने और अगली योजना वृद्धि के लिए तैयार होने की अनुमति मिलती है। और एसएएफई के प्रथम संस्करणों ने भी इसे जटिल पुनरावृत्ति के रूप में डिज़ाइन किया था, अर्थात् उत्पाद को प्रवाहित करने से पहले उसे स्थिर या कठोर करने के लिए किया जाता है । यह उच्च एकीकरण परिवेशों के साथ कार्य करने की जटिलताओं पर आधारित था जहां निर्भरताएं कई स्तिथियों को अंत तक परीक्षण करने से रोकती थीं। एसएएफई की इसके लिए आलोचना की गई क्योंकि यह एंटी-एजाइल या वॉटरफॉल तत्व का प्रतिनिधित्व करता था, किन्तु यह 90-दिन की वेतन वृद्धि के अनुरूप था जो की 13 सप्ताह बनाता है, और यदि दो सप्ताह की स्प्रिंट करते हैं तो आपको उनमें से छह की आवश्यकता होती है और साथ ही सप्ताह की योजना या जटिल होने का चक्र की आवश्यकता होती है।<ref>{{Cite news|url=https://neilkillick.wordpress.com/2012/03/21/the-horror-of-the-scaled-agile-framework/|title=स्केल्ड एजाइल फ्रेमवर्क की भयावहता|last=Killick|first=Neil|date=21 March 2012|work=Agile, Scrum, Kanban, Lean, and everything that's in between|access-date=2017-11-27}}</ref> यह एसएएफई के वर्तमान समय से संस्करणों में सम्मिलित नहीं है। | ||
==कार्यान्वयन== | ==कार्यान्वयन== | ||
| Line 40: | Line 42: | ||
इस प्रकार से कई असमान प्रथाओं को एकत्रित करने के लिए एसएएफई की आलोचना की गई है।<ref>{{Cite web|url=https://www.infoq.com/news/2013/08/safe|title=Has SAFe Cracked the Large Agile Adoption Nut?|last=Elssamadisy|first=Amr|website=InfoQ|access-date=2017-11-11}}</ref> | इस प्रकार से कई असमान प्रथाओं को एकत्रित करने के लिए एसएएफई की आलोचना की गई है।<ref>{{Cite web|url=https://www.infoq.com/news/2013/08/safe|title=Has SAFe Cracked the Large Agile Adoption Nut?|last=Elssamadisy|first=Amr|website=InfoQ|access-date=2017-11-11}}</ref> | ||
=== एसएएफई रूपरेखा === | === एसएएफई रूपरेखा === | ||
एसएएफई संस्करण 5.1 में, चार कॉन्फ़िगरेशन हैं: आवश्यक | एसएएफई संस्करण 5.1 में, चार कॉन्फ़िगरेशन हैं: आवश्यक पोर्टफोलियो, उच्च समाधान और पूर्ण:<ref>{{Cite book|url=https://books.google.com/books?id=qppNDwAAQBAJ|title=डमीज़ के लिए उद्यम चपलता|last=Rose|first=Doug|date=2018|publisher=John Wiley & Sons|isbn=9781119446095|pages=87–89|language=en}}</ref> | ||
* एसेंशियल एसएएफई अधिक मूलभूत कॉन्फ़िगरेशन है। यह आवश्यक अधिक महत्वपूर्ण तत्वों का वर्णन करता है और इसका उद्देश्य रूपरेखा के अधिकांश लाभ प्रदान करना है। इसमें टीम और प्रोग्राम स्तर (जिसे वह एजाइल रिलीज़ ट्रेन या एआरटी कहते हैं) सम्मिलित की जाती हैं। | * एसेंशियल एसएएफई अधिक मूलभूत कॉन्फ़िगरेशन है। यह आवश्यक अधिक महत्वपूर्ण तत्वों का वर्णन करता है और इसका उद्देश्य रूपरेखा के अधिकांश लाभ प्रदान करना है। इसमें टीम और प्रोग्राम स्तर (जिसे वह एजाइल रिलीज़ ट्रेन या एआरटी कहते हैं) सम्मिलित की जाती हैं। | ||
* उच्च समाधान एसएएफई कई कार्यक्रमों में समन्वय और सिंक्रनाइज़ेशन की अनुमति देता है, किन्तु पोर्टफोलियो पर विचार किए | * उच्च समाधान एसएएफई कई कार्यक्रमों में समन्वय और सिंक्रनाइज़ेशन की अनुमति देता है, किन्तु पोर्टफोलियो पर विचार किए बिना एसएएफई के प्राचीन संस्करणों में, इस स्तर को [[ मूल्य धारा |मूल्य धारा]] के रूप में संदर्भित किया गया था। | ||
* पोर्टफोलियो एसएएफई में रणनीतिक दिशा, निवेश फंडिंग और लीन गवर्नेंस की चिंताएं सम्मिलित होती हैं। | * पोर्टफोलियो एसएएफई में रणनीतिक दिशा, निवेश फंडिंग और लीन गवर्नेंस की चिंताएं सम्मिलित होती हैं। | ||
* पूर्ण एसएएफई अन्य तीन स्तरों को जोड़ती है। | * पूर्ण एसएएफई अन्य तीन स्तरों को जोड़ती है। | ||
=== प्रमाणपत्र === | === प्रमाणपत्र === | ||
स्केल्ड एजाइल [[व्यावसायिक प्रमाणन (कंप्यूटर प्रौद्योगिकी)]] प्रदान करता है | स्केल्ड एजाइल [[व्यावसायिक प्रमाणन (कंप्यूटर प्रौद्योगिकी)]] प्रदान करता है जो की विभिन्न क्षेत्रों और ज्ञान स्तरों को कवर करता है।<ref>{{cite web|url=http://www.scaledagile.com/which-course/|title=प्रमाणीकरण|work=Scaled Agile|access-date=19 February 2016}}</ref> | ||
== यह भी देखें == | == यह भी देखें == | ||
* स्क्रम (सॉफ़्टवेयर डेवलपमेंट) या स्क्रम ऑफ़ स्क्रम | * स्क्रम (सॉफ़्टवेयर डेवलपमेंट) या स्क्रम ऑफ़ स्क्रम | ||
Revision as of 10:30, 13 July 2023
| Part of a series on |
| Software development |
|---|
स्केल्ड एजाइल फ्रेमवर्क (एसएएफई) संगठन और वर्कफ़्लो पैटर्न का सेट होता है जिसका उद्देश्य नवाचारों के स्केलिंग लीन सॉफ्टवेयर विकास और एजाइल सॉफ्टवेयर विकास प्रथाओं में उद्यमों का मार्गदर्शन करना है।[1][2] और अनुशासित तीव्र डिलीवरी (डीएडी) के साथ, एसएएफई उन बढ़ती संख्या में रूपरेखा में से है जो की टीम से आगे बढ़ने पर आने वाली समस्याओं का समाधान करना चाहता है।[3][4]
एसएएफई बड़ी संख्या में चुस्त टीमों के बीच संरेखण, सहयोग और वितरण को बढ़ावा देता है। इसे ज्ञान, तीव्र सॉफ्टवेयर विकास, दुबले उत्पाद विकास और सिस्टम सोच के तीन प्राथमिक निकायों का लाभ उठाकर, चिकित्सकों द्वारा और उनके लिए विकसित किया गया था।[5]
इस प्रकार से स्केल्ड एजाइल फ्रेमवर्क के लिए प्राथमिक संदर्भ मूल रूप से उत्पाद प्रबंधन (या अन्य परियोजना हितधारक) से परियोजना प्रशासन, कार्यक्रम प्रबंधन और सॉफ्टवेयर डेवलपर के माध्यम से ग्राहक तक कैसे प्रवाहित होता है, इसकी बड़ी तस्वीर का विकास था।[6][7] तीव्र समुदाय के अन्य लोगों के सहयोग से, इसे उत्तरोत्तर परिष्कृत किया गया और फिर पहली बार 2007 की पुस्तक में औपचारिक रूप से वर्णित किया गया।[8] रूपरेखा का विकास और सार्वजनिक रूप से साझा किया जाना प्रवाहित है; अकादमी और मान्यता योजना के साथ उन लोगों का समर्थन करना जो एसएएफई को अपनाने में दूसरों को प्रयुक्त करना है ,और समर्थन करना या प्रशिक्षित करना चाहते हैं।
इस प्रकार से 2011 में इसकी प्रथम रिलीज से प्रारंभ होकर, छह प्रमुख संस्करण प्रवाहित किए गए हैं[9] जबकि नवीनतम संस्करण, संस्करण 6.0, मार्च 2023 में प्रवाहित किया गया था।[10]
जबकि एसएएफई को तीव्र प्रथाओं को बढ़ाने के लिए अधिक आम दृष्टिकोण के रूप में पहचाना जा रहा है (30 प्रतिशत और बढ़ रहा है),[11][12],[13] इसे अत्यधिक पदानुक्रम और अनम्य होने के कारण आलोचना भी मिली है।[14] परिचित प्रक्रियाओं को समान रखते हुए संगठनों को एजाइल सॉफ्टवेयर विकास को अपनाने का भ्रम देने के लिए भी इसकी आलोचना होती है।[15]
तीव्र सिद्धांतों और प्रथाओं को बढ़ाने की चुनौतियाँ
लंबी योजना क्षितिज का सामना करना
इस प्रकार से विकास टीमें सामान्यतः अपने बैकलॉग को दो से तीन पुनरावृत्तियों तक परिष्कृत करती हैं, किन्तु उच्च संगठनों में उत्पाद विपणन टीम को बाजार के प्रति अपनी प्रतिबद्धताओं और ग्राहकों के साथ चर्चा के लिए आगे की योजना बनाने की आवश्यकता होती है।[16] चूंकि वे सदैव अधिक उच्च स्तर, 12 से 18 महीने के रोडमैप के साथ कार्य करेंगे, फिर तीन महीने के कार्य के लिए टीमों के साथ मिलकर योजना बनाएंगे। और विकास टीमें अभी भी 2-3 पुनरावृत्तियों में विस्तृत परिशोधन में लगेंगी, केवल अगले पुनरावृत्ति के लिए विस्तृत कार्य योजनाओं में सम्मिलित है ।
उत्तरदायित्व के अमूर्त स्तरों पर तीव्र बने रहना
चूंकि विकास टीमों के पास कई फ़्रेमवर्क हैं जो की परिभाषित करते हैं कि उन्हें कैसे तीव्र होना चाहिए, किन्तु प्रबंधन के लिए इसका वर्णन करने वाली अधिक कम होती है। और एसएएफई उन समूहों को कई समान सिद्धांत प्रदान करता है, जैसे क्रॉस-फ़ंक्शनल टीम, जो उत्तरदायी और योजना (उत्पाद और पोर्टफोलियो) के अधिक अमूर्त स्तरों को संभालते हैं।
प्रत्यायोजित प्राधिकार के साथ व्यवहार
इस प्रकार से स्क्रम (सॉफ्टवेयर विकास) में, उत्पाद स्वामी से संपूर्ण उत्पाद जीवनचक्र उत्पाद जीवनचक्र की उत्तरदायी लेने की अपेक्षा की जाती है, जिसमें विकास निर्णयों के निवेश पर रिटर्न, साथ ही बाजार में प्रदर्शन भी सम्मिलित होते है। और उच्च माप पर विकास पर, संगठन कई टीम बैकलॉग पर दृश्य चाहता है, जैसे कि उत्पाद प्रबंधक द्वारा प्रदान किया गया था ।[17] चूंकि एसएएफई मानता है कि उत्पाद स्वामी की भूमिका उत्पाद प्रबंधन के साथ बैठती है, फिर भी उत्पाद मालिकों को विकास संगठन में अलग करने के लिए इसकी आलोचना की गई है।[18]
डिलिवरेबल्स को सिंक्रनाइज़ करना
एजाइल फ्रेमवर्क को विकास टीम को स्वायत्त बनाने और अपने कार्य करने के विधि को डिजाइन करने के लिए स्वतंत्र बनाने के लिए डिज़ाइन किया गया है। चूंकि एसएएफई स्वीकार करता है कि कई दसियों या सैकड़ों विकास टीमों के माप पर, टीमों के लिए पूर्ण रूप से आत्म-संगठित होना तीव्र से अराजक हो जाता है।[19] इसलिए यह इस पर कुछ बाधाएँ होती है, जिससे जहाँ टीमें ही उत्पाद पर कार्य कर रही हों, उनकी डिलिवरेबल्स को साथ प्रवाहित करने के लिए ठीक प्रकार से सिंक्रनाइज़ किया जा सकता है, चूंकि यह ऐसा क्षेत्र रहा है जिसमें एसएएफई की आलोचना की गई है।[17][18]
नवप्रवर्तन और योजना के लिए समय देना
इस प्रकार से एसएएफई योजना चक्र रिलीज के बाद अतिरिक्त पुनरावृत्ति को सम्मिलित करने की अनुशंसा करता है, जिससे टीमों को अपनी प्रथाओं में सुधार करने और अगली योजना वृद्धि के लिए तैयार होने की अनुमति मिलती है। और एसएएफई के प्रथम संस्करणों ने भी इसे जटिल पुनरावृत्ति के रूप में डिज़ाइन किया था, अर्थात् उत्पाद को प्रवाहित करने से पहले उसे स्थिर या कठोर करने के लिए किया जाता है । यह उच्च एकीकरण परिवेशों के साथ कार्य करने की जटिलताओं पर आधारित था जहां निर्भरताएं कई स्तिथियों को अंत तक परीक्षण करने से रोकती थीं। एसएएफई की इसके लिए आलोचना की गई क्योंकि यह एंटी-एजाइल या वॉटरफॉल तत्व का प्रतिनिधित्व करता था, किन्तु यह 90-दिन की वेतन वृद्धि के अनुरूप था जो की 13 सप्ताह बनाता है, और यदि दो सप्ताह की स्प्रिंट करते हैं तो आपको उनमें से छह की आवश्यकता होती है और साथ ही सप्ताह की योजना या जटिल होने का चक्र की आवश्यकता होती है।[20] यह एसएएफई के वर्तमान समय से संस्करणों में सम्मिलित नहीं है।
कार्यान्वयन
एसएएफई के अंतर्निहित सिद्धांत
इस प्रकार से लेखकों के अनुसार, एसएएफई दस अंतर्निहित अवधारणाओं पर आधारित है, जोकी उपस्तिथ दुबले और तीव्र सिद्धांतों के साथ-साथ अवलोकन से ली गई हैं:[21]
- आर्थिक दृष्टिकोण अपनाएं
- सिस्टम विचार प्रयुक्त करें
- परिवर्तनशीलता मान लें; विकल्प सुरक्षित रखें
- तीव्र से एकीकृत शिक्षण चक्रों के साथ वृद्धिशील रूप से निर्माण करें
- कार्य प्रणालियों के वस्तुनिष्ठ मूल्यांकन पर आधार मील के पत्थर
- चल रहे कार्य की कल्पना करें और उसे सीमित करें, बैच आकार कम करें, और कतार की लंबाई प्रबंधित करें
- केडेंस (समय) प्रयुक्त करें, क्रॉस-डोमेन योजना के साथ सिंक्रनाइज़ करें
- ज्ञान कार्यकर्ताओं की आंतरिक प्रेरणा को अनलॉक करें
- विकेंद्रीकरण निर्णय लेना
- मूल्य के चारों ओर व्यवस्थित करें
इस प्रकार से कई असमान प्रथाओं को एकत्रित करने के लिए एसएएफई की आलोचना की गई है।[22]
एसएएफई रूपरेखा
एसएएफई संस्करण 5.1 में, चार कॉन्फ़िगरेशन हैं: आवश्यक पोर्टफोलियो, उच्च समाधान और पूर्ण:[23]
- एसेंशियल एसएएफई अधिक मूलभूत कॉन्फ़िगरेशन है। यह आवश्यक अधिक महत्वपूर्ण तत्वों का वर्णन करता है और इसका उद्देश्य रूपरेखा के अधिकांश लाभ प्रदान करना है। इसमें टीम और प्रोग्राम स्तर (जिसे वह एजाइल रिलीज़ ट्रेन या एआरटी कहते हैं) सम्मिलित की जाती हैं।
- उच्च समाधान एसएएफई कई कार्यक्रमों में समन्वय और सिंक्रनाइज़ेशन की अनुमति देता है, किन्तु पोर्टफोलियो पर विचार किए बिना एसएएफई के प्राचीन संस्करणों में, इस स्तर को मूल्य धारा के रूप में संदर्भित किया गया था।
- पोर्टफोलियो एसएएफई में रणनीतिक दिशा, निवेश फंडिंग और लीन गवर्नेंस की चिंताएं सम्मिलित होती हैं।
- पूर्ण एसएएफई अन्य तीन स्तरों को जोड़ती है।
प्रमाणपत्र
स्केल्ड एजाइल व्यावसायिक प्रमाणन (कंप्यूटर प्रौद्योगिकी) प्रदान करता है जो की विभिन्न क्षेत्रों और ज्ञान स्तरों को कवर करता है।[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
