लीन सॉफ्टवेयर विकास: Difference between revisions
No edit summary |
No edit summary |
||
| Line 45: | Line 45: | ||
चूंकि सॉफ्टवेयर विकास सदैव कुछ अनिश्चितताओं से सम्बंधित होता है, इसलिए सेट-आधारित या विकल्प-आधारित दृष्टिकोण के साथ उत्तम परिणाम प्राप्त किए जाने चाहिए, निर्णयों में यथासंभव देरी करनी चाहिए जब तक कि वे तथ्यों के आधार पर न किए जाएं, न कि अनिश्चित मान्यताओं एवं भविष्यवाणियों पर करनी चाहिए । प्रणाली जितनी अधिक जटिल होती है, उसमें परिवर्तन की उतनी ही अधिक क्षमता निर्मित की जानी चाहिए, इस प्रकार महत्वपूर्ण एवं महत्वपूर्ण प्रतिबद्धताओं में देरी को सक्षम किया जा सकता है। पुनरावृत्तीय दृष्टिकोण इस सिद्धांत को बढ़ावा देता है, परिवर्तनों को अनुकूलित करने एवं त्रुटियों को सुधारने की क्षमता, जो प्रणाली के निरंतर होने के पश्चात खोजे जाने पर बहुत मूल्यवान हो सकती है। | चूंकि सॉफ्टवेयर विकास सदैव कुछ अनिश्चितताओं से सम्बंधित होता है, इसलिए सेट-आधारित या विकल्प-आधारित दृष्टिकोण के साथ उत्तम परिणाम प्राप्त किए जाने चाहिए, निर्णयों में यथासंभव देरी करनी चाहिए जब तक कि वे तथ्यों के आधार पर न किए जाएं, न कि अनिश्चित मान्यताओं एवं भविष्यवाणियों पर करनी चाहिए । प्रणाली जितनी अधिक जटिल होती है, उसमें परिवर्तन की उतनी ही अधिक क्षमता निर्मित की जानी चाहिए, इस प्रकार महत्वपूर्ण एवं महत्वपूर्ण प्रतिबद्धताओं में देरी को सक्षम किया जा सकता है। पुनरावृत्तीय दृष्टिकोण इस सिद्धांत को बढ़ावा देता है, परिवर्तनों को अनुकूलित करने एवं त्रुटियों को सुधारने की क्षमता, जो प्रणाली के निरंतर होने के पश्चात खोजे जाने पर बहुत मूल्यवान हो सकती है। | ||
:सेट-आधारित विकास के साथ | :सेट-आधारित विकास के साथ उदाहरण के लिए, यदि किसी कार के लिए नए ब्रेक प्रणाली की आवश्यकता है, तो तीन समूहें के समान समस्या का समाधान डिज़ाइन कर सकती हैं। प्रत्येक समूह समस्या क्षेत्र के विषय में सीखती है एवं संभावित समाधान तैयार करती है। जैसे ही कोई समाधान अनुचित समझा जाता है, उसे निकाल दिया जाता है। किसी अवधि के अंत में, बचे हुए डिज़ाइनों की अपेक्षा की जाती है एवं एक का चयन होता है, संभवतः दूसरों से सीखने के आधार पर कुछ संशोधनों के साथ अंतिम संभावित क्षण तक प्रतिबद्धता को स्थगित करने का बड़ा उदाहरण है। बड़े अप-फ्रंट डिज़ाइन द्वारा लाए गए संयोग को कम करने के लिए सॉफ़्टवेयर निर्णय भी इस अभ्यास से लाभान्वित हो सकते हैं। इसके अतिरिक्त, ऐसे कई कार्यान्वयन होंगे जो उचित माध्यम से कार्य करते हैं, फिर भी भिन्न होते हैं। इनका उपयोग दोष-सहिष्णु प्रणालियों को प्रस्तावित करने के लिए किया जा सकता है जो कई कार्यान्वयनों में सभी इनपुट एवं आउटपुट की शुद्धता का परीक्षण करते हैं। | ||
चुस्त सॉफ्टवेयर विकास दृष्टिकोण ग्राहकों के लिए विकल्पों के निर्माण को आगे बढ़ा सकता है, इस प्रकार कुछ महत्वपूर्ण निर्णयों में देरी हो सकती है जब तक कि ग्राहकों को उनकी आवश्यकताओं का उत्तम एहसास न हो जाए। इससे परिवर्तनों को पश्चात में स्वीकार करने एवं पूर्व के बहुमूल्य प्रौद्योगिकी-बद्ध निर्णयों को रोकने की भी अनुमति प्राप्त होती है। इसका तात्पर्य यह नहीं है कि कोई योजना सम्मिलित नहीं होनी चाहिए, इसके विपरीत, योजना गतिविधियों को विभिन्न विकल्पों पर ध्यान केंद्रित करना चाहिए एवं वर्तमान स्थिति को अनुकूलित करना चाहिए, साथ ही तीव्रता से कार्रवाई के लिए पैटर्न स्थापित करके भ्रमित स्थितियों को स्पष्ट करना चाहिए। जैसे ही यह एहसास हो कि वे स्वतंत्र नहीं हैं, विभिन्न विकल्पों का मूल्यांकन करना प्रभावी है, परन्तु देर से निर्णय लेने के लिए आवश्यक लचीलापन प्रदान करते हैं। | |||
=== जितनी शीघ्र हो सके वितरित करना === | === जितनी शीघ्र हो सके वितरित करना === | ||
तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, | तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, परन्तु सबसे तीव्र है। जितनी शीघ्र अंतिम उत्पाद आभाव में किसी बड़े दोष के वितरित किया जाएगा, उतनी ही शीघ्र प्रतिक्रिया प्राप्त की जा सकती है, एवं आगामी पुनरावृत्ति में सम्मिलित किया जा सकता है। पुनरावृत्तियाँ जितनी छोटी होंगी, समूह के अंदर सीखना एवं संचार उतना ही उत्तम होगा। गति के साथ, निर्णयों में देरी हो सकती है। स्पीड ग्राहक की वर्तमान आवश्यकताओं को पूर्ण करने का आश्वासन देती है, न कि वह जो उन्हें कल चाहिए थी। इससे उन्हें इस विषय में निर्णय लेने में देरी करने का अवसर मिलता है कि उन्हें वास्तव में क्या चाहिए जब तक कि वे उत्तम ज्ञान प्राप्त न कर लें। ग्राहक गुणवत्तापूर्ण (व्यावसायिक) उत्पाद की तीव्र डिलीवरी को महत्व देते हैं। | ||
[[बिल्कुल समय पर (व्यवसाय)]]व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में | [[बिल्कुल समय पर (व्यवसाय)]]व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में प्रस्तावितकिया जा सकता है, इसकी विशिष्ट आवश्यकताओं एवं वातावरण को पहचानते हुए। यह आवश्यक परिणाम प्रस्तुत करके एवं समूह को खुद को व्यवस्थित करने एवं एक विशिष्ट Iteration#Project प्रबंधन के लिए आवश्यक परिणाम को पूर्ण करने के लिए कार्यों को विभाजित करने की अनुमति देकर प्राप्त किया जाता है। शुरुआत में, ग्राहक आवश्यक इनपुट प्रदान करता है। इसे बस छोटे कार्ड या उपयोगकर्ता कहानी में प्रस्तुत किया जा सकता है - डेवलपर्स प्रत्येक कार्ड के [[कार्यान्वयन]] के लिए आवश्यक समय का अनुमान लगाते हैं। इस प्रकार कार्य संगठन [[कानबन कार्ड]] में बदल जाता है | स्व-खींचने वाली प्रणाली - प्रत्येक सुबह एक [[आमने - सामने की मीटिंग]] के समय, समूह का प्रत्येक सदस्य समीक्षा करता है कि कल क्या किया गया है, आज एवं कल क्या किया जाना है, एवं किसी भी आवश्यक इनपुट के लिए संकेत देता है सहकर्मियों या ग्राहक से. इसके लिए प्रक्रिया में पारदर्शिता की आवश्यकता है, जो समूह संचार के लिए भी फायदेमंद है। | ||
इस सिद्धांत में अंतर्निहित मिथक यह है कि जल्दबाजी विनाश लाती है। हालाँकि, कम कार्यान्वयन से पता चला है कि आउटपुट को जल्द से जल्द देखने एवं उसका विश्लेषण करने के लिए तीव्री से समूह करना एक अच्छा अभ्यास है। | इस सिद्धांत में अंतर्निहित मिथक यह है कि जल्दबाजी विनाश लाती है। हालाँकि, कम कार्यान्वयन से पता चला है कि आउटपुट को जल्द से जल्द देखने एवं उसका विश्लेषण करने के लिए तीव्री से समूह करना एक अच्छा अभ्यास है। | ||
=== समूह को सशक्त बनाएं === | === समूह को सशक्त बनाएं === | ||
अधिकांश व्यवसायों में संगठन में निर्णय लेने के विषय में एक पारंपरिक धारणा रही है - प्रबंधक श्रमिकों को बताते हैं कि उन्हें अपना कार्य कैसे करना है। वर्क-आउट प्रौद्योगिकी में, भूमिकाएँ बदल जाती हैं - प्रबंधकों को सिखाया जाता है कि [[सॉफ्टवेयर डेवलपर]] की बात कैसे सुनी जाए, ताकि वे उत्तम माध्यम से समझा सकें कि क्या कार्रवाई की जा सकती है, साथ ही सुधार के लिए सुझाव भी दे सकते हैं। दुबला दृष्टिकोण चुस्त सिद्धांत का अनुसरण करता है<ref>{{cite web|url=https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/|title=12 Principles Behind the Agile Manifesto - Agile Alliance|date=4 November 2015|website=agilealliance.org}}</ref> प्रेरित व्यक्तियों के इर्द-गिर्द परियोजनाएँ बनाएं [...] एवं कार्य पूर्ण करने के लिए उन पर भरोसा करना,<ref name="LinesAmbler2012">{{cite book|author1=Mark Lines|author2=Scott W. Ambler|title=Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise|url=https://books.google.com/books?id=SLIkMhB2ew0C&pg=PA54|year=2012|publisher=IBM Press|isbn=978-0-13-281013-5|pages=54–}}</ref> प्रगति को प्रोत्साहित करना, त्रुटियों को पकड़ना एवं बाधाओं को दूर करना, | अधिकांश व्यवसायों में संगठन में निर्णय लेने के विषय में एक पारंपरिक धारणा रही है - प्रबंधक श्रमिकों को बताते हैं कि उन्हें अपना कार्य कैसे करना है। वर्क-आउट प्रौद्योगिकी में, भूमिकाएँ बदल जाती हैं - प्रबंधकों को सिखाया जाता है कि [[सॉफ्टवेयर डेवलपर]] की बात कैसे सुनी जाए, ताकि वे उत्तम माध्यम से समझा सकें कि क्या कार्रवाई की जा सकती है, साथ ही सुधार के लिए सुझाव भी दे सकते हैं। दुबला दृष्टिकोण चुस्त सिद्धांत का अनुसरण करता है<ref>{{cite web|url=https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/|title=12 Principles Behind the Agile Manifesto - Agile Alliance|date=4 November 2015|website=agilealliance.org}}</ref> प्रेरित व्यक्तियों के इर्द-गिर्द परियोजनाएँ बनाएं [...] एवं कार्य पूर्ण करने के लिए उन पर भरोसा करना,<ref name="LinesAmbler2012">{{cite book|author1=Mark Lines|author2=Scott W. Ambler|title=Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise|url=https://books.google.com/books?id=SLIkMhB2ew0C&pg=PA54|year=2012|publisher=IBM Press|isbn=978-0-13-281013-5|pages=54–}}</ref> प्रगति को प्रोत्साहित करना, त्रुटियों को पकड़ना एवं बाधाओं को दूर करना, परन्तु [[ सूक्ष्म प्रबंधन ]]|माइक्रो-मैनेजिंग नहीं। | ||
एक एवं गलत धारणा लोगों को [[संसाधन]] मानने की रही है। सांख्यिकीय डेटा शीट के दृष्टिकोण से लोग संसाधन हो सकते हैं, | एक एवं गलत धारणा लोगों को [[संसाधन]] मानने की रही है। सांख्यिकीय डेटा शीट के दृष्टिकोण से लोग संसाधन हो सकते हैं, परन्तु सॉफ्टवेयर विकास के साथ-साथ किसी भी संगठनात्मक व्यवसाय में, लोगों को केवल कार्यों की सूची एवं आश्वासन के अलावा कुछ एवं भी चाहिए होता है कि पूर्ण होने के समय उन्हें परेशान नहीं किया जाएगा। कार्यों का. लोगों को कार्य करने के लिए [[प्रेरणा]] एवं उच्च उद्देश्य की आवश्यकता होती है - पहुंच योग्य वास्तविकता के अंदर उद्देश्य, इस आश्वासन के साथ कि समूह अपनी प्रतिबद्धताओं का चयन कर सकती है। डेवलपर्स को ग्राहक तक पहुंच दी जानी चाहिए; [[टीम लीडर|समूह लीडर]] को कठिन परिस्थितियों में सहायता एवं सहायता प्रदान करनी चाहिए, साथ ही यह भी सुनिश्चित करना चाहिए कि संदेह समूह की भावना को व्यर्थ न करे। लोगों का सम्मान करना एवं उनके कार्य को स्वीकार करना समूह को सशक्त बनाने का एक तरीका है। | ||
=== === में अखंडता बनाएं | === === में अखंडता बनाएं | ||
ग्राहक को प्रणाली का समग्र अनुभव होना आवश्यक है। यह तथाकथित कथित अखंडता है: इसका विज्ञापन, समूह, तैनाती, पहुंच कैसे की जा रही है, इसका उपयोग कितना सहज है, इसकी कीमत एवं यह समस्याओं को कितनी अच्छी तरह हल करता है। | ग्राहक को प्रणाली का समग्र अनुभव होना आवश्यक है। यह तथाकथित कथित अखंडता है: इसका विज्ञापन, समूह, तैनाती, पहुंच कैसे की जा रही है, इसका उपयोग कितना सहज है, इसकी कीमत एवं यह समस्याओं को कितनी अच्छी तरह हल करता है। | ||
वैचारिक अखंडता का | वैचारिक अखंडता का तात्पर्य है कि प्रणाली के अलग-अलग घटक लचीलेपन, रखरखाव, दक्षता एवं जवाबदेही के मध्य संतुलन के साथ समग्र रूप से अच्छी तरह से कार्य करते हैं। इसे समस्या क्षेत्र को समझकर एवं उसे एक ही समय में हल करके प्राप्त किया जा सकता है, क्रमिक रूप से नहीं। आवश्यक जानकारी छोटे बैच के टुकड़ों में प्राप्त होती है - एक बड़े हिस्से में नहीं - अधिमानतः आमने-सामने संचार द्वारा एवं किसी लिखित दस्तावेज से नहीं। सूचना का प्रवाह दोनों दिशाओं में स्थिर होना चाहिए - ग्राहक से डेवलपर्स तक एवं वापस, इस प्रकार अलगाव में लंबे विकास के पश्चात जानकारी की बड़ी तनावपूर्ण मात्रा से बचा जा सकता है। | ||
अभिन्न वास्तुकला की दिशा में स्वस्थ तरीकों में से एक है [[ पुनर्रचना ]]। जैसे-जैसे मूल कोड आधार में अधिक सुविधाएँ जोड़ी जाती हैं, आगे सुधार जोड़ना उतना ही कठिन होता जाता है। रीफैक्टरिंग कोड में सरलता, स्पष्टता, न्यूनतम सुविधाओं को बनाए रखने के विषय में है। कोड में दोप्रत्येकाव ख़राब कोड डिज़ाइन का संकेत है एवं इससे बचा जाना चाहिए (अर्थात स्वयं को न दोप्रत्येकाएँ | अभिन्न वास्तुकला की दिशा में स्वस्थ तरीकों में से एक है [[ पुनर्रचना ]]। जैसे-जैसे मूल कोड आधार में अधिक सुविधाएँ जोड़ी जाती हैं, आगे सुधार जोड़ना उतना ही कठिन होता जाता है। रीफैक्टरिंग कोड में सरलता, स्पष्टता, न्यूनतम सुविधाओं को बनाए रखने के विषय में है। कोड में दोप्रत्येकाव ख़राब कोड डिज़ाइन का संकेत है एवं इससे बचा जाना चाहिए (अर्थात स्वयं को न दोप्रत्येकाएँ प्रस्तावितकरके)। पूर्ण एवं स्वचालित निर्माण प्रक्रिया के साथ डेवलपर एवं ग्राहक परीक्षणों का एक पूर्ण एवं स्वचालित सूट होना चाहिए, जिसमें प्रणाली की वर्तमान स्थिति के समान संस्करण, सिंक्रनाइज़ेशन एवं शब्दार्थ हों। अंत में संपूर्ण परीक्षण के साथ अखंडता को सत्यापित किया जाना चाहिए, इस प्रकार यह सुनिश्चित किया जाना चाहिए कि प्रणाली वही करता है जो ग्राहक उससे अपेक्षा करता है। स्वचालित परीक्षणों को भी उत्पादन प्रक्रिया का हिस्सा माना जाता है, एवं इसलिए यदि वे मूल्य नहीं जोड़ते हैं तो उन्हें व्यर्थ माना जाना चाहिए। स्वचालित परीक्षण एक लक्ष्य नहीं होना चाहिए, बल्कि अंत का एक साधन होना चाहिए, विशेष रूप से दोषों को कम करना। | ||
=== संपूर्ण को अनुकूलित करना === | === संपूर्ण को अनुकूलित करना === | ||
आधुनिक सॉफ्टवेयर प्रणाली केवल उनके भागों का योग नहीं हैं, बल्कि उनकी अंतःक्रियाओं का उत्पाद भी हैं। सॉफ़्टवेयर में दोष विकास प्रक्रिया के समय जमा होते रहते हैं - बड़े कार्यों को छोटे कार्यों में विघटित करके, एवं विकास के विभिन्न चरणों को मानकीकृत करके, दोषों के मूल कारणों को ढूंढा जाना चाहिए एवं समाप्त किया जाना चाहिए। प्रणाली जितनी बड़ी होगी, उसके विकास में उतने अधिक संगठन सम्मिलित होंगे एवं जितने अधिक हिस्से अलग-अलग समूहों द्वारा विकसित किए जाएंगे, सुचारू रूप से वार्तालाप करने वाले घटकों के साथ एक प्रणाली का निर्माण करने के लिए विभिन्न विक्रेताओं के मध्य अच्छी तरह से परिभाषित संबंधों का महत्व उतना ही अधिक होगा। विकास की लंबी अवधि के समय, एक मजबूत उपठेकेदार नेटवर्क अल्पकालिक लाभ अनुकूलन की अपेक्षा में कहीं अधिक फायदेमंद है, जो [[ जीत-जीत का खेल ]]|विन-विन संबंधों को सक्षम नहीं करता है। | आधुनिक सॉफ्टवेयर प्रणाली केवल उनके भागों का योग नहीं हैं, बल्कि उनकी अंतःक्रियाओं का उत्पाद भी हैं। सॉफ़्टवेयर में दोष विकास प्रक्रिया के समय जमा होते रहते हैं - बड़े कार्यों को छोटे कार्यों में विघटित करके, एवं विकास के विभिन्न चरणों को मानकीकृत करके, दोषों के मूल कारणों को ढूंढा जाना चाहिए एवं समाप्त किया जाना चाहिए। प्रणाली जितनी बड़ी होगी, उसके विकास में उतने अधिक संगठन सम्मिलित होंगे एवं जितने अधिक हिस्से अलग-अलग समूहों द्वारा विकसित किए जाएंगे, सुचारू रूप से वार्तालाप करने वाले घटकों के साथ एक प्रणाली का निर्माण करने के लिए विभिन्न विक्रेताओं के मध्य अच्छी तरह से परिभाषित संबंधों का महत्व उतना ही अधिक होगा। विकास की लंबी अवधि के समय, एक मजबूत उपठेकेदार नेटवर्क अल्पकालिक लाभ अनुकूलन की अपेक्षा में कहीं अधिक फायदेमंद है, जो [[ जीत-जीत का खेल ]]|विन-विन संबंधों को सक्षम नहीं करता है। | ||
ठोस, वास्तविक जीवन की स्थिति में | ठोस, वास्तविक जीवन की स्थिति में प्रस्तावितकरने से पूर्व, किसी परियोजना के सभी सदस्यों द्वारा लीन सोच को अच्छी तरह से समझा जाना चाहिए। बड़ा सोचो, छोटे कार्य करो, शीघ्र असफल हो जाओ; तीव्री से सीखें<ref name="PoppendieckPoppendieck2003">{{cite book|author1=Mary Poppendieck|author2=Tom Poppendieck|title=Lean Software Development: An Agile Toolkit|url=https://books.google.com/books?id=hQk4S7asBi4C&pg=PA182|year=2003|publisher=Addison-Wesley Professional|isbn=978-0-321-15078-3|pages=182–}}</ref> - ये नारे क्षेत्र को समझने के महत्व एवं संपूर्ण सॉफ्टवेयर विकास प्रक्रिया में लीन सिद्धांतों को प्रस्तावितकरने की उपयुक्तता का सारांश देते हैं। केवल जब सभी सामान्य सिद्धांतों को एक साथ कार्यान्वित किया जाता है, कार्यकाजी माहौल के संबंध में मजबूत सामान्य ज्ञान के साथ जोड़ा जाता है, तो सॉफ्टवेयर विकास में सफलता का आधार होता है। | ||
== लीन सॉफ्टवेयर अभ्यास == | == लीन सॉफ्टवेयर अभ्यास == | ||
लीन सॉफ़्टवेयर विकास पद्धतियाँ, या जिसे पोपेन्डिएक्स टूल कहते हैं, फुर्तीली सॉफ़्टवेयर विकास में मूल समकक्षों से थोड़ा सा पुनर्स्थापित किया गया है। ऐसी प्रथाओं के | लीन सॉफ़्टवेयर विकास पद्धतियाँ, या जिसे पोपेन्डिएक्स टूल कहते हैं, फुर्तीली सॉफ़्टवेयर विकास में मूल समकक्षों से थोड़ा सा पुनर्स्थापित किया गया है। ऐसी प्रथाओं के उदाहरणों में सम्मिलित हैं: | ||
* मुदा देखना (जापानी शब्द) | * मुदा देखना (जापानी शब्द) | ||
Revision as of 21:43, 4 July 2023
| Part of a series on |
| Software development |
|---|
लीन सॉफ्टवेयर विकास, अनुत्पादक निर्माण सिद्धांतों एवं प्रथाओं का सॉफ्टवेयर विकास डोमेन में अनुवाद है। टोयोटा उत्पादन प्रणाली से अनुकूलित,[1] यह चुस्त सॉफ्टवेयर विकास समुदाय के अंदर प्रो-लीन उपसंस्कृति के समर्थन से उभर रहा है। लीन ठोस वैचारिक आकृति, मूल्यों एवं सिद्धांतों के साथ-साथ अनुभव से प्राप्त उच्च प्रथाओं को प्रस्तुत करता है, जो सक्रिय संगठनों का समर्थन करते हैं।
उत्पत्ति
अभिव्यक्ति लीन सॉफ्टवेयर विकास की उत्पत्ति 2003 में मैरी पॉपपेंडिएक एवं टॉम पॉपपेंडिएक द्वारा इसी नाम से लिखी गई पुस्तक में हुई थी।[2] पुस्तक पारंपरिक लीन मैन्युफैक्चरिंग अवलोकन के साथ-साथ 22 उपकरणों के सेट को पुनर्स्थापित करती है एवं उपकरणों की अपेक्षा संबंधित चुस्त प्रथाओं से करती है। एजाइल सॉफ्टवेयर विकास समुदाय में पॉपपेंडिक्स की भागीदारी, जिसमें कई एजाइल सम्मेलनों में वार्तालाप भी सम्मिलित है [3] इसके परिणामस्वरूप ऐसी अवधारणाओं को सक्रिय समुदाय के अंदर अधिक व्यापक रूप से स्वीकार किया जा रहा है।
लीन सिद्धांत
लीन विकास को सात सिद्धांतों द्वारा संक्षेपित किया जा सकता है, जो लीन विनिर्माण सिद्धांतों की अवधारणा के बहुत समीप हैं:[4]
- अपशिष्ट को निकालना
- सीखने का विस्तार करना
- यथासंभव देर से निर्णय लेना
- जितनी शीघ्र हो सके वितरित करना
- समूह को सशक्त बनाना
- अखंडता का निर्माण करना
- संपूर्ण को अनुकूलित करना
अपशिष्ट को समाप्त करना
लीन दर्शन ग्राहक के लिए मूल्य न बढ़ाने वाली प्रत्येक वस्तु को व्यर्थ (मुडा (जापानी शब्द)) मानता है। ऐसे अपशिष्ट में सम्मिलित हो सकते हैं:[5]
- आंशिक रूप से किया गया कार्य
- सॉफ़्टवेयर ब्लोट
- पुनः सीखना
- कार्य स्विचिंग (मनोविज्ञान)
- प्रतीक्षा
- हैंडऑफ़
- सॉफ़्टवेयर बग
- प्रबंध गतिविधियाँ
अपशिष्ट को समाप्त करने के लिए व्यक्ति को इसे पहचानने में सक्षम होना चाहिए। यदि किसी गतिविधि को दरकिनार किया जा सकता है या उसके आभाव में परिणाम प्राप्त किया जा सकता है, तो यह विनाश है। सॉफ़्टवेयर विकास प्रक्रिया के समय आंशिक रूप से की गई कोडिंग को अंततः छोड़ दिया जाना व्यर्थ है। अतिरिक्त सुविधाएं जैसे कागजी कार्रवाई एवं ग्राहकों द्वारा प्रायः उपयोग न की जाने वाली सुविधाएं व्यर्थ हैं। लोगों को कार्यों के मध्य परिवर्तित करना व्यर्थ है (संदर्भ-स्विचिंग में सम्मिलित लोगों द्वारा समय व्यर्थ किया जाता है, एवं प्रायः विलुप्त कर दिया जाता है)। अन्य गतिविधियों, समूहों, प्रक्रियाओं की प्रतीक्षा करना व्यर्थ है। कार्य पूर्ण करने के लिए आवश्यकताओं को पुनः सीखना विनाश है। दोष एवं निम्न गुणवत्ता अपशिष्ट हैं। प्रबंधकीय उपरिव्यय जो वास्तविक मूल्य उत्पन्न नहीं करता वह विनाश है।
अपशिष्ट की पहचान करने के लिए मान स्ट्रीम मानचित्रण प्रौद्योगिकी का उपयोग किया जाता है। दूसरा कदम अपशिष्ट के स्रोतों को इंगित करना एवं उन्हें समाप्त करना है। अपशिष्ट निकालना निरन्तर तब तक होना चाहिए जब तक कि आवश्यक प्रक्रियाएँ एवं प्रक्रियाएँ समाप्त न हो जाएँ।
सीखने का विस्तार करें
सॉफ़्टवेयर विकास कोड लिखते समय पुनरावृत्तियों पर आधारित सतत सीखने की प्रक्रिया है। सॉफ़्टवेयर डिज़ाइन ऐसी समस्या-समाधान प्रक्रिया है जिसमें डेवलपर्स कोड लिखते हैं एवं उन्होंने क्या सीखा है। सॉफ़्टवेयर का मूल्य उपयोग के लिए आवश्यकताओं के अनुरूप में नहीं अपितु उपयुक्तता में मापा जाता है। अधिक दस्तावेज़ीकरण या विस्तृत योजना जोड़ने के अतिरिक्त, कोड लिखकर एवं निर्माण करके विभिन्न विचारों को स्वीकार किया जा सकता है। अंतिम-उपयोगकर्ताओं को स्क्रीन प्रस्तुत करके एवं उनका इनपुट प्राप्त करके उपयोगकर्ता आवश्यकताओं को एकत्र करने की प्रक्रिया को सरल बनाया जा सकता है। कोड लिखते ही परीक्षण करके दोषों के संचय को रोका जाना चाहिए।
सीखने की प्रक्रिया को छोटे पुनरावृत्ति चक्रों के उपयोग से तीव्र किया जाता है - प्रत्येक को रिफैक्टरिंग एवं एकीकरण परीक्षण के साथ जोड़ा जाता है। ग्राहकों के साथ लघु फीडबैक सत्रों के माध्यम से फीडबैक बढ़ाने से विकास के वर्तमान चरण को निर्धारित करने एवं भविष्य में सुधार के लिए प्रयासों को समायोजित करने में सहायता मिलती है। उन छोटे सत्रों के समय, ग्राहक प्रतिनिधि एवं विकास समूह दोनों डोमेन समस्या के विषय में अधिक सीखते हैं एवं आगे के विकास के लिए संभावित समाधान ढूंढते हैं। इस प्रकार ग्राहक विकास प्रयासों के सम्मिलित परिणाम के आधार पर अपनी आवश्यकताओं को उत्तम माध्यम से समझते हैं, एवं डेवलपर्स सीखते हैं कि उन आवश्यकताओं को उत्तम माध्यम से कैसे पूर्ण किया जाए। ग्राहक के साथ संचार एवं सीखने की प्रक्रिया में विचार सेट-आधारित विकास है, यह भविष्य के समाधान की बाधाओं को संप्रेषित करने पर ध्यान केंद्रित करता है, न कि संभावित समाधानों पर, इस प्रकार ग्राहक के साथ वार्तालाप के माध्यम से समाधान के जन्म को बढ़ावा देता है।
यथासंभव देर से निर्णय लेना
चूंकि सॉफ्टवेयर विकास सदैव कुछ अनिश्चितताओं से सम्बंधित होता है, इसलिए सेट-आधारित या विकल्प-आधारित दृष्टिकोण के साथ उत्तम परिणाम प्राप्त किए जाने चाहिए, निर्णयों में यथासंभव देरी करनी चाहिए जब तक कि वे तथ्यों के आधार पर न किए जाएं, न कि अनिश्चित मान्यताओं एवं भविष्यवाणियों पर करनी चाहिए । प्रणाली जितनी अधिक जटिल होती है, उसमें परिवर्तन की उतनी ही अधिक क्षमता निर्मित की जानी चाहिए, इस प्रकार महत्वपूर्ण एवं महत्वपूर्ण प्रतिबद्धताओं में देरी को सक्षम किया जा सकता है। पुनरावृत्तीय दृष्टिकोण इस सिद्धांत को बढ़ावा देता है, परिवर्तनों को अनुकूलित करने एवं त्रुटियों को सुधारने की क्षमता, जो प्रणाली के निरंतर होने के पश्चात खोजे जाने पर बहुत मूल्यवान हो सकती है।
- सेट-आधारित विकास के साथ उदाहरण के लिए, यदि किसी कार के लिए नए ब्रेक प्रणाली की आवश्यकता है, तो तीन समूहें के समान समस्या का समाधान डिज़ाइन कर सकती हैं। प्रत्येक समूह समस्या क्षेत्र के विषय में सीखती है एवं संभावित समाधान तैयार करती है। जैसे ही कोई समाधान अनुचित समझा जाता है, उसे निकाल दिया जाता है। किसी अवधि के अंत में, बचे हुए डिज़ाइनों की अपेक्षा की जाती है एवं एक का चयन होता है, संभवतः दूसरों से सीखने के आधार पर कुछ संशोधनों के साथ अंतिम संभावित क्षण तक प्रतिबद्धता को स्थगित करने का बड़ा उदाहरण है। बड़े अप-फ्रंट डिज़ाइन द्वारा लाए गए संयोग को कम करने के लिए सॉफ़्टवेयर निर्णय भी इस अभ्यास से लाभान्वित हो सकते हैं। इसके अतिरिक्त, ऐसे कई कार्यान्वयन होंगे जो उचित माध्यम से कार्य करते हैं, फिर भी भिन्न होते हैं। इनका उपयोग दोष-सहिष्णु प्रणालियों को प्रस्तावित करने के लिए किया जा सकता है जो कई कार्यान्वयनों में सभी इनपुट एवं आउटपुट की शुद्धता का परीक्षण करते हैं।
चुस्त सॉफ्टवेयर विकास दृष्टिकोण ग्राहकों के लिए विकल्पों के निर्माण को आगे बढ़ा सकता है, इस प्रकार कुछ महत्वपूर्ण निर्णयों में देरी हो सकती है जब तक कि ग्राहकों को उनकी आवश्यकताओं का उत्तम एहसास न हो जाए। इससे परिवर्तनों को पश्चात में स्वीकार करने एवं पूर्व के बहुमूल्य प्रौद्योगिकी-बद्ध निर्णयों को रोकने की भी अनुमति प्राप्त होती है। इसका तात्पर्य यह नहीं है कि कोई योजना सम्मिलित नहीं होनी चाहिए, इसके विपरीत, योजना गतिविधियों को विभिन्न विकल्पों पर ध्यान केंद्रित करना चाहिए एवं वर्तमान स्थिति को अनुकूलित करना चाहिए, साथ ही तीव्रता से कार्रवाई के लिए पैटर्न स्थापित करके भ्रमित स्थितियों को स्पष्ट करना चाहिए। जैसे ही यह एहसास हो कि वे स्वतंत्र नहीं हैं, विभिन्न विकल्पों का मूल्यांकन करना प्रभावी है, परन्तु देर से निर्णय लेने के लिए आवश्यक लचीलापन प्रदान करते हैं।
जितनी शीघ्र हो सके वितरित करना
तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, परन्तु सबसे तीव्र है। जितनी शीघ्र अंतिम उत्पाद आभाव में किसी बड़े दोष के वितरित किया जाएगा, उतनी ही शीघ्र प्रतिक्रिया प्राप्त की जा सकती है, एवं आगामी पुनरावृत्ति में सम्मिलित किया जा सकता है। पुनरावृत्तियाँ जितनी छोटी होंगी, समूह के अंदर सीखना एवं संचार उतना ही उत्तम होगा। गति के साथ, निर्णयों में देरी हो सकती है। स्पीड ग्राहक की वर्तमान आवश्यकताओं को पूर्ण करने का आश्वासन देती है, न कि वह जो उन्हें कल चाहिए थी। इससे उन्हें इस विषय में निर्णय लेने में देरी करने का अवसर मिलता है कि उन्हें वास्तव में क्या चाहिए जब तक कि वे उत्तम ज्ञान प्राप्त न कर लें। ग्राहक गुणवत्तापूर्ण (व्यावसायिक) उत्पाद की तीव्र डिलीवरी को महत्व देते हैं।
बिल्कुल समय पर (व्यवसाय)व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में प्रस्तावितकिया जा सकता है, इसकी विशिष्ट आवश्यकताओं एवं वातावरण को पहचानते हुए। यह आवश्यक परिणाम प्रस्तुत करके एवं समूह को खुद को व्यवस्थित करने एवं एक विशिष्ट Iteration#Project प्रबंधन के लिए आवश्यक परिणाम को पूर्ण करने के लिए कार्यों को विभाजित करने की अनुमति देकर प्राप्त किया जाता है। शुरुआत में, ग्राहक आवश्यक इनपुट प्रदान करता है। इसे बस छोटे कार्ड या उपयोगकर्ता कहानी में प्रस्तुत किया जा सकता है - डेवलपर्स प्रत्येक कार्ड के कार्यान्वयन के लिए आवश्यक समय का अनुमान लगाते हैं। इस प्रकार कार्य संगठन कानबन कार्ड में बदल जाता है | स्व-खींचने वाली प्रणाली - प्रत्येक सुबह एक आमने - सामने की मीटिंग के समय, समूह का प्रत्येक सदस्य समीक्षा करता है कि कल क्या किया गया है, आज एवं कल क्या किया जाना है, एवं किसी भी आवश्यक इनपुट के लिए संकेत देता है सहकर्मियों या ग्राहक से. इसके लिए प्रक्रिया में पारदर्शिता की आवश्यकता है, जो समूह संचार के लिए भी फायदेमंद है।
इस सिद्धांत में अंतर्निहित मिथक यह है कि जल्दबाजी विनाश लाती है। हालाँकि, कम कार्यान्वयन से पता चला है कि आउटपुट को जल्द से जल्द देखने एवं उसका विश्लेषण करने के लिए तीव्री से समूह करना एक अच्छा अभ्यास है।
समूह को सशक्त बनाएं
अधिकांश व्यवसायों में संगठन में निर्णय लेने के विषय में एक पारंपरिक धारणा रही है - प्रबंधक श्रमिकों को बताते हैं कि उन्हें अपना कार्य कैसे करना है। वर्क-आउट प्रौद्योगिकी में, भूमिकाएँ बदल जाती हैं - प्रबंधकों को सिखाया जाता है कि सॉफ्टवेयर डेवलपर की बात कैसे सुनी जाए, ताकि वे उत्तम माध्यम से समझा सकें कि क्या कार्रवाई की जा सकती है, साथ ही सुधार के लिए सुझाव भी दे सकते हैं। दुबला दृष्टिकोण चुस्त सिद्धांत का अनुसरण करता है[6] प्रेरित व्यक्तियों के इर्द-गिर्द परियोजनाएँ बनाएं [...] एवं कार्य पूर्ण करने के लिए उन पर भरोसा करना,[7] प्रगति को प्रोत्साहित करना, त्रुटियों को पकड़ना एवं बाधाओं को दूर करना, परन्तु सूक्ष्म प्रबंधन |माइक्रो-मैनेजिंग नहीं।
एक एवं गलत धारणा लोगों को संसाधन मानने की रही है। सांख्यिकीय डेटा शीट के दृष्टिकोण से लोग संसाधन हो सकते हैं, परन्तु सॉफ्टवेयर विकास के साथ-साथ किसी भी संगठनात्मक व्यवसाय में, लोगों को केवल कार्यों की सूची एवं आश्वासन के अलावा कुछ एवं भी चाहिए होता है कि पूर्ण होने के समय उन्हें परेशान नहीं किया जाएगा। कार्यों का. लोगों को कार्य करने के लिए प्रेरणा एवं उच्च उद्देश्य की आवश्यकता होती है - पहुंच योग्य वास्तविकता के अंदर उद्देश्य, इस आश्वासन के साथ कि समूह अपनी प्रतिबद्धताओं का चयन कर सकती है। डेवलपर्स को ग्राहक तक पहुंच दी जानी चाहिए; समूह लीडर को कठिन परिस्थितियों में सहायता एवं सहायता प्रदान करनी चाहिए, साथ ही यह भी सुनिश्चित करना चाहिए कि संदेह समूह की भावना को व्यर्थ न करे। लोगों का सम्मान करना एवं उनके कार्य को स्वीकार करना समूह को सशक्त बनाने का एक तरीका है।
=== === में अखंडता बनाएं ग्राहक को प्रणाली का समग्र अनुभव होना आवश्यक है। यह तथाकथित कथित अखंडता है: इसका विज्ञापन, समूह, तैनाती, पहुंच कैसे की जा रही है, इसका उपयोग कितना सहज है, इसकी कीमत एवं यह समस्याओं को कितनी अच्छी तरह हल करता है।
वैचारिक अखंडता का तात्पर्य है कि प्रणाली के अलग-अलग घटक लचीलेपन, रखरखाव, दक्षता एवं जवाबदेही के मध्य संतुलन के साथ समग्र रूप से अच्छी तरह से कार्य करते हैं। इसे समस्या क्षेत्र को समझकर एवं उसे एक ही समय में हल करके प्राप्त किया जा सकता है, क्रमिक रूप से नहीं। आवश्यक जानकारी छोटे बैच के टुकड़ों में प्राप्त होती है - एक बड़े हिस्से में नहीं - अधिमानतः आमने-सामने संचार द्वारा एवं किसी लिखित दस्तावेज से नहीं। सूचना का प्रवाह दोनों दिशाओं में स्थिर होना चाहिए - ग्राहक से डेवलपर्स तक एवं वापस, इस प्रकार अलगाव में लंबे विकास के पश्चात जानकारी की बड़ी तनावपूर्ण मात्रा से बचा जा सकता है।
अभिन्न वास्तुकला की दिशा में स्वस्थ तरीकों में से एक है पुनर्रचना । जैसे-जैसे मूल कोड आधार में अधिक सुविधाएँ जोड़ी जाती हैं, आगे सुधार जोड़ना उतना ही कठिन होता जाता है। रीफैक्टरिंग कोड में सरलता, स्पष्टता, न्यूनतम सुविधाओं को बनाए रखने के विषय में है। कोड में दोप्रत्येकाव ख़राब कोड डिज़ाइन का संकेत है एवं इससे बचा जाना चाहिए (अर्थात स्वयं को न दोप्रत्येकाएँ प्रस्तावितकरके)। पूर्ण एवं स्वचालित निर्माण प्रक्रिया के साथ डेवलपर एवं ग्राहक परीक्षणों का एक पूर्ण एवं स्वचालित सूट होना चाहिए, जिसमें प्रणाली की वर्तमान स्थिति के समान संस्करण, सिंक्रनाइज़ेशन एवं शब्दार्थ हों। अंत में संपूर्ण परीक्षण के साथ अखंडता को सत्यापित किया जाना चाहिए, इस प्रकार यह सुनिश्चित किया जाना चाहिए कि प्रणाली वही करता है जो ग्राहक उससे अपेक्षा करता है। स्वचालित परीक्षणों को भी उत्पादन प्रक्रिया का हिस्सा माना जाता है, एवं इसलिए यदि वे मूल्य नहीं जोड़ते हैं तो उन्हें व्यर्थ माना जाना चाहिए। स्वचालित परीक्षण एक लक्ष्य नहीं होना चाहिए, बल्कि अंत का एक साधन होना चाहिए, विशेष रूप से दोषों को कम करना।
संपूर्ण को अनुकूलित करना
आधुनिक सॉफ्टवेयर प्रणाली केवल उनके भागों का योग नहीं हैं, बल्कि उनकी अंतःक्रियाओं का उत्पाद भी हैं। सॉफ़्टवेयर में दोष विकास प्रक्रिया के समय जमा होते रहते हैं - बड़े कार्यों को छोटे कार्यों में विघटित करके, एवं विकास के विभिन्न चरणों को मानकीकृत करके, दोषों के मूल कारणों को ढूंढा जाना चाहिए एवं समाप्त किया जाना चाहिए। प्रणाली जितनी बड़ी होगी, उसके विकास में उतने अधिक संगठन सम्मिलित होंगे एवं जितने अधिक हिस्से अलग-अलग समूहों द्वारा विकसित किए जाएंगे, सुचारू रूप से वार्तालाप करने वाले घटकों के साथ एक प्रणाली का निर्माण करने के लिए विभिन्न विक्रेताओं के मध्य अच्छी तरह से परिभाषित संबंधों का महत्व उतना ही अधिक होगा। विकास की लंबी अवधि के समय, एक मजबूत उपठेकेदार नेटवर्क अल्पकालिक लाभ अनुकूलन की अपेक्षा में कहीं अधिक फायदेमंद है, जो जीत-जीत का खेल |विन-विन संबंधों को सक्षम नहीं करता है।
ठोस, वास्तविक जीवन की स्थिति में प्रस्तावितकरने से पूर्व, किसी परियोजना के सभी सदस्यों द्वारा लीन सोच को अच्छी तरह से समझा जाना चाहिए। बड़ा सोचो, छोटे कार्य करो, शीघ्र असफल हो जाओ; तीव्री से सीखें[8] - ये नारे क्षेत्र को समझने के महत्व एवं संपूर्ण सॉफ्टवेयर विकास प्रक्रिया में लीन सिद्धांतों को प्रस्तावितकरने की उपयुक्तता का सारांश देते हैं। केवल जब सभी सामान्य सिद्धांतों को एक साथ कार्यान्वित किया जाता है, कार्यकाजी माहौल के संबंध में मजबूत सामान्य ज्ञान के साथ जोड़ा जाता है, तो सॉफ्टवेयर विकास में सफलता का आधार होता है।
लीन सॉफ्टवेयर अभ्यास
लीन सॉफ़्टवेयर विकास पद्धतियाँ, या जिसे पोपेन्डिएक्स टूल कहते हैं, फुर्तीली सॉफ़्टवेयर विकास में मूल समकक्षों से थोड़ा सा पुनर्स्थापित किया गया है। ऐसी प्रथाओं के उदाहरणों में सम्मिलित हैं:
- मुदा देखना (जापानी शब्द)
- मान स्ट्रीम मानचित्रण
- बाधाओं का सिद्धांत|सेट-आधारित विकास
- कानबन कार्ड
- कतारबद्ध सिद्धांत
- प्रेरणा
- माप
- परीक्षण संचालित विकास
चूंकि एजाइल सॉफ्टवेयर विकास एजाइल मेनिफेस्टो में व्यक्त मूल्यों एवं सिद्धांतों के आधार पर विधियों एवं प्रथाओं के एक सेट के लिए एक हाइपोनिमी एवं हाइपरनिमी है, इसलिए लीन सॉफ्टवेयर विकास को एक एजाइल सॉफ्टवेयर विकास विधि माना जाता है।[9]
यह भी देखें
- चरम कार्यक्रम
- डेवऑप्स
- कानबन (विकास)
- कानबन बोर्ड
- दुबला एकीकरण
- लीन सेवाएं
- स्क्रम (विकास)
संदर्भ
- ↑ Yasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time, Third edition, Norcross, GA: Engineering & Management Press, ISBN 0-412-83930-X.
- ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. ISBN 978-0-321-15078-3.
- ↑ Mary Poppendieck: "The role of leadership in software development" https://www.youtube.com/watch?v=ypEMdjslEOI
- ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 13–15. ISBN 978-0-321-15078-3.
- ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 19–22. ISBN 978-0-321-15078-3.
- ↑ "12 Principles Behind the Agile Manifesto - Agile Alliance". agilealliance.org. 4 November 2015.
- ↑ Mark Lines; Scott W. Ambler (2012). Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise. IBM Press. pp. 54–. ISBN 978-0-13-281013-5.
- ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 182–. ISBN 978-0-321-15078-3.
- ↑ "What is Agile Software Development?". agilealliance.org. 29 June 2015.
अग्रिम पठन
- Ladas, Corey (January 2008). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press. ISBN 978-0-578-00214-9.
- Ries, Eric (September 2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business. ISBN 978-0307887894.
