लीन सॉफ्टवेयर विकास: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 10: Line 10:
अभिव्यक्ति लीन सॉफ्टवेयर विकास की उत्पत्ति 2003 में मैरी पॉपपेंडिएक और टॉम पॉपपेंडिएक द्वारा इसी नाम से लिखी गई पुस्तक में हुई थी।<ref name="1Poppendieck2003">{{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}}</ref> पुस्तक पारंपरिक लीन मैन्युफैक्चरिंग अवलोकन के साथ-साथ 22 उपकरणों के सेट को पुनर्स्थापित करती है और उपकरणों की अपेक्षा संबंधित चुस्त प्रथाओं से करती है। एजाइल सॉफ्टवेयर विकास समुदाय में पॉपपेंडिक्स की भागीदारी, जिसमें कई एजाइल सम्मेलनों में  वार्तालाप भी सम्मिलित है <ref>Mary Poppendieck: "The role of leadership in software development"  https://www.youtube.com/watch?v=ypEMdjslEOI</ref> इसके परिणामस्वरूप ऐसी अवधारणाओं को सक्रिय समुदाय के अंदर अधिक व्यापक रूप से स्वीकार किया जा रहा है।
अभिव्यक्ति लीन सॉफ्टवेयर विकास की उत्पत्ति 2003 में मैरी पॉपपेंडिएक और टॉम पॉपपेंडिएक द्वारा इसी नाम से लिखी गई पुस्तक में हुई थी।<ref name="1Poppendieck2003">{{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}}</ref> पुस्तक पारंपरिक लीन मैन्युफैक्चरिंग अवलोकन के साथ-साथ 22 उपकरणों के सेट को पुनर्स्थापित करती है और उपकरणों की अपेक्षा संबंधित चुस्त प्रथाओं से करती है। एजाइल सॉफ्टवेयर विकास समुदाय में पॉपपेंडिक्स की भागीदारी, जिसमें कई एजाइल सम्मेलनों में  वार्तालाप भी सम्मिलित है <ref>Mary Poppendieck: "The role of leadership in software development"  https://www.youtube.com/watch?v=ypEMdjslEOI</ref> इसके परिणामस्वरूप ऐसी अवधारणाओं को सक्रिय समुदाय के अंदर अधिक व्यापक रूप से स्वीकार किया जा रहा है।


== दुबले सिद्धांत ==
== लीन सिद्धांत ==


लीन विकास को सात सिद्धांतों द्वारा संक्षेपित किया जा सकता है, जो लीन विनिर्माण सिद्धांतों की अवधारणा के बहुत करीब हैं:<ref name="2Poppendieck2003">{{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=13–15}}</ref>
लीन विकास को सात सिद्धांतों द्वारा संक्षेपित किया जा सकता है, जो लीन विनिर्माण सिद्धांतों की अवधारणा के बहुत समीप हैं:<ref name="2Poppendieck2003">{{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=13–15}}</ref>
##कचरे को हटाना
##अपशिष्ट को निकालना
##सीखना बढ़ाना
##सीखने का विस्तार करना
##यथासंभव देर से निर्णय लेना
##यथासंभव देर से निर्णय लेना
##जितनी जल्दी हो सके वितरित करें
##जितनी शीघ्र हो सके वितरण करना
##टीम को सशक्त बनाना
##समूह को सशक्त बनाना
##अखंडता का निर्माण करें
##अखंडता का निर्माण करना
##संपूर्ण को अनुकूलित करें
##संपूर्ण को अनुकूलित करना


===अपशिष्ट को खत्म करें ===
===अपशिष्ट को समाप्त करना ===
लीन दर्शन ग्राहक के लिए मूल्य न बढ़ाने वाली हर चीज को बेकार (मुडा (जापानी शब्द)) मानता है। ऐसे कचरे में सम्मिलित हो सकते हैं:<ref name="3Poppendieck2003">{{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=19–22}}</ref>
लीन दर्शन ग्राहक के लिए मूल्य न बढ़ाने वाली प्रत्येक वस्तु को व्यर्थ (मुडा (जापानी शब्द)) मानता है। ऐसे अपशिष्ट में सम्मिलित हो सकते हैं:<ref name="3Poppendieck2003">{{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=19–22}}</ref>
# आंशिक रूप से किया गया काम
# आंशिक रूप से किया गया कार्य
# [[ सॉफ़्टवेयर ब्लोट ]]
# [[ सॉफ़्टवेयर ब्लोट ]]
# पुनः सीखना
# पुनः सीखना
# [[कार्य स्विचिंग (मनोविज्ञान)]]
# [[कार्य स्विचिंग (मनोविज्ञान)]]
# इंतज़ार में
# प्रतीक्षा
# हैंडऑफ़
# हैंडऑफ़
# [[ सॉफ़्टवेयर बग ]]
# [[ सॉफ़्टवेयर बग |सॉफ़्टवेयर बग]]
# [[प्रबंध]]
# [[प्रबंध|प्रबंध गतिविधियाँ]]


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


कचरे की पहचान करने के लिए [[ मान स्ट्रीम मानचित्रण ]] तकनीक का उपयोग किया जाता है। दूसरा कदम कचरे के स्रोतों को इंगित करना और उन्हें खत्म करना है। अपशिष्ट-हटाना लगातार तब तक होना चाहिए जब तक कि आवश्यक प्रक्रियाएँ और प्रक्रियाएँ समाप्त न हो जाएँ।
अपशिष्ट की पहचान करने के लिए [[ मान स्ट्रीम मानचित्रण ]] तकनीक का उपयोग किया जाता है। दूसरा कदम अपशिष्ट के स्रोतों को इंगित करना और उन्हें समाप्त करना है। अपशिष्ट-हटाना लगातार तब तक होना चाहिए जब तक कि आवश्यक प्रक्रियाएँ और प्रक्रियाएँ समाप्त न हो जाएँ।


=== सीखने को बढ़ाना ===
=== सीखने को बढ़ाना ===
Line 41: Line 41:
अधिक दस्तावेज़ीकरण या विस्तृत योजना जोड़ने के बजाय, कोड लिखकर और निर्माण करके विभिन्न विचारों को आज़माया जा सकता है। अंतिम-उपयोगकर्ताओं को स्क्रीन प्रस्तुत करके और उनका इनपुट प्राप्त करके उपयोगकर्ता आवश्यकताओं को एकत्र करने की प्रक्रिया को सरल बनाया जा सकता है। कोड लिखते ही परीक्षण चलाकर दोषों के संचय को रोका जाना चाहिए।
अधिक दस्तावेज़ीकरण या विस्तृत योजना जोड़ने के बजाय, कोड लिखकर और निर्माण करके विभिन्न विचारों को आज़माया जा सकता है। अंतिम-उपयोगकर्ताओं को स्क्रीन प्रस्तुत करके और उनका इनपुट प्राप्त करके उपयोगकर्ता आवश्यकताओं को एकत्र करने की प्रक्रिया को सरल बनाया जा सकता है। कोड लिखते ही परीक्षण चलाकर दोषों के संचय को रोका जाना चाहिए।


सीखने की प्रक्रिया को छोटे पुनरावृत्ति चक्रों के उपयोग से तेज किया जाता है - प्रत्येक को रिफैक्टरिंग और एकीकरण परीक्षण के साथ जोड़ा जाता है। ग्राहकों के साथ लघु फीडबैक सत्रों के माध्यम से फीडबैक बढ़ाने से विकास के वर्तमान चरण को निर्धारित करने और भविष्य में सुधार के लिए प्रयासों को समायोजित करने में मदद मिलती है। उन छोटे सत्रों के दौरान, [[ग्राहक प्रतिनिधि]] और विकास टीम दोनों डोमेन समस्या के बारे में अधिक सीखते हैं और आगे के विकास के लिए संभावित समाधान ढूंढते हैं। इस प्रकार ग्राहक विकास प्रयासों के मौजूदा परिणाम के आधार पर अपनी जरूरतों को बेहतर ढंग से समझते हैं, और डेवलपर्स सीखते हैं कि उन जरूरतों को बेहतर ढंग से कैसे पूरा किया जाए। ग्राहक के साथ संचार और सीखने की प्रक्रिया में एक और विचार सेट-आधारित विकास है - यह भविष्य के समाधान की बाधाओं को संप्रेषित करने पर ध्यान केंद्रित करता है, न कि संभावित समाधानों पर, इस प्रकार ग्राहक के साथ  वार्तालाप के माध्यम से समाधान के जन्म को बढ़ावा देता है।{{Jargon-statement|date=June 2018}}
सीखने की प्रक्रिया को छोटे पुनरावृत्ति चक्रों के उपयोग से तेज किया जाता है - प्रत्येक को रिफैक्टरिंग और एकीकरण परीक्षण के साथ जोड़ा जाता है। ग्राहकों के साथ लघु फीडबैक सत्रों के माध्यम से फीडबैक बढ़ाने से विकास के वर्तमान चरण को निर्धारित करने और भविष्य में सुधार के लिए प्रयासों को समायोजित करने में मदद मिलती है। उन छोटे सत्रों के दौरान, [[ग्राहक प्रतिनिधि]] और विकास समूह दोनों डोमेन समस्या के बारे में अधिक सीखते हैं और आगे के विकास के लिए संभावित समाधान ढूंढते हैं। इस प्रकार ग्राहक विकास प्रयासों के मौजूदा परिणाम के आधार पर अपनी जरूरतों को बेहतर ढंग से समझते हैं, और डेवलपर्स सीखते हैं कि उन जरूरतों को बेहतर ढंग से कैसे पूरा किया जाए। ग्राहक के साथ संचार और सीखने की प्रक्रिया में एक और विचार सेट-आधारित विकास है - यह भविष्य के समाधान की बाधाओं को संप्रेषित करने पर ध्यान केंद्रित करता है, न कि संभावित समाधानों पर, इस प्रकार ग्राहक के साथ  वार्तालाप के माध्यम से समाधान के जन्म को बढ़ावा देता है।{{Jargon-statement|date=June 2018}}


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


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


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


=== जितनी जल्दी हो सके वितरित करें ===
=== जितनी शीघ्र हो सके वितरित करना ===
तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, बल्कि सबसे तेज़ है। जितनी जल्दी अंतिम उत्पाद बिना किसी बड़े दोष के वितरित किया जाएगा, उतनी ही जल्दी प्रतिक्रिया प्राप्त की जा सकती है, और अगले पुनरावृत्ति में सम्मिलित किया जा सकता है। पुनरावृत्तियाँ जितनी छोटी होंगी, टीम के अंदर सीखना और संचार उतना ही बेहतर होगा। गति के साथ, निर्णयों में देरी हो सकती है। स्पीड ग्राहक की वर्तमान जरूरतों को पूरा करने का आश्वासन देती है, न कि वह जो उन्हें कल चाहिए थी। इससे उन्हें इस बारे में निर्णय लेने में देरी करने का अवसर मिलता है कि उन्हें वास्तव में क्या चाहिए जब तक कि वे बेहतर ज्ञान प्राप्त न कर लें। ग्राहक गुणवत्तापूर्ण (व्यावसायिक) उत्पाद की तीव्र डिलीवरी को महत्व देते हैं।
तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, बल्कि सबसे तेज़ है। जितनी शीघ्र अंतिम उत्पाद बिना किसी बड़े दोष के वितरित किया जाएगा, उतनी ही शीघ्र प्रतिक्रिया प्राप्त की जा सकती है, और अगले पुनरावृत्ति में सम्मिलित किया जा सकता है। पुनरावृत्तियाँ जितनी छोटी होंगी, समूह के अंदर सीखना और संचार उतना ही बेहतर होगा। गति के साथ, निर्णयों में देरी हो सकती है। स्पीड ग्राहक की वर्तमान जरूरतों को पूरा करने का आश्वासन देती है, न कि वह जो उन्हें कल चाहिए थी। इससे उन्हें इस बारे में निर्णय लेने में देरी करने का अवसर मिलता है कि उन्हें वास्तव में क्या चाहिए जब तक कि वे बेहतर ज्ञान प्राप्त न कर लें। ग्राहक गुणवत्तापूर्ण (व्यावसायिक) उत्पाद की तीव्र डिलीवरी को महत्व देते हैं।


[[बिल्कुल समय पर (व्यवसाय)]]व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में लागू किया जा सकता है, इसकी विशिष्ट आवश्यकताओं और वातावरण को पहचानते हुए। यह आवश्यक परिणाम प्रस्तुत करके और टीम को खुद को व्यवस्थित करने और एक विशिष्ट Iteration#Project प्रबंधन के लिए आवश्यक परिणाम को पूरा करने के लिए कार्यों को विभाजित करने की अनुमति देकर प्राप्त किया जाता है। शुरुआत में, ग्राहक आवश्यक इनपुट प्रदान करता है। इसे बस छोटे कार्ड या उपयोगकर्ता कहानी में प्रस्तुत किया जा सकता है - डेवलपर्स प्रत्येक कार्ड के [[कार्यान्वयन]] के लिए आवश्यक समय का अनुमान लगाते हैं। इस प्रकार कार्य संगठन [[कानबन कार्ड]] में बदल जाता है | स्व-खींचने वाली प्रणाली - प्रत्येक सुबह एक [[आमने - सामने की मीटिंग]] के दौरान, टीम का प्रत्येक सदस्य समीक्षा करता है कि कल क्या किया गया है, आज और कल क्या किया जाना है, और किसी भी आवश्यक इनपुट के लिए संकेत देता है सहकर्मियों या ग्राहक से. इसके लिए प्रक्रिया में पारदर्शिता की आवश्यकता है, जो टीम संचार के लिए भी फायदेमंद है।
[[बिल्कुल समय पर (व्यवसाय)]]व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में लागू किया जा सकता है, इसकी विशिष्ट आवश्यकताओं और वातावरण को पहचानते हुए। यह आवश्यक परिणाम प्रस्तुत करके और समूह को खुद को व्यवस्थित करने और एक विशिष्ट 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> - ये नारे क्षेत्र को समझने के महत्व और संपूर्ण सॉफ्टवेयर विकास प्रक्रिया में लीन सिद्धांतों को लागू करने की उपयुक्तता का सारांश देते हैं। केवल जब सभी सामान्य सिद्धांतों को एक साथ कार्यान्वित किया जाता है, कामकाजी माहौल के संबंध में मजबूत सामान्य ज्ञान के साथ जोड़ा जाता है, तो सॉफ्टवेयर विकास में सफलता का आधार होता है।
ठोस, वास्तविक जीवन की स्थिति में लागू करने से पहले, किसी परियोजना के सभी सदस्यों द्वारा लीन सोच को अच्छी तरह से समझा जाना चाहिए। बड़ा सोचो, छोटे कार्य करो, शीघ्र असफल हो जाओ; तेजी से सीखें<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 20:28, 4 July 2023

Not to be confused with Lean (proof assistant).
Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

लीन सॉफ्टवेयर विकास, अनुत्पादक निर्माण सिद्धांतों और प्रथाओं का सॉफ्टवेयर विकास डोमेन में अनुवाद है। टोयोटा उत्पादन प्रणाली से अनुकूलित,[1] यह चुस्त सॉफ्टवेयर विकास समुदाय के अंदर प्रो-लीन उपसंस्कृति के समर्थन से उभर रहा है। लीन ठोस वैचारिक आकृति, मूल्यों और सिद्धांतों के साथ-साथ अनुभव से प्राप्त उच्च प्रथाओं को प्रस्तुत करता है, जो सक्रिय संगठनों का समर्थन करते हैं।

उत्पत्ति

अभिव्यक्ति लीन सॉफ्टवेयर विकास की उत्पत्ति 2003 में मैरी पॉपपेंडिएक और टॉम पॉपपेंडिएक द्वारा इसी नाम से लिखी गई पुस्तक में हुई थी।[2] पुस्तक पारंपरिक लीन मैन्युफैक्चरिंग अवलोकन के साथ-साथ 22 उपकरणों के सेट को पुनर्स्थापित करती है और उपकरणों की अपेक्षा संबंधित चुस्त प्रथाओं से करती है। एजाइल सॉफ्टवेयर विकास समुदाय में पॉपपेंडिक्स की भागीदारी, जिसमें कई एजाइल सम्मेलनों में वार्तालाप भी सम्मिलित है [3] इसके परिणामस्वरूप ऐसी अवधारणाओं को सक्रिय समुदाय के अंदर अधिक व्यापक रूप से स्वीकार किया जा रहा है।

लीन सिद्धांत

लीन विकास को सात सिद्धांतों द्वारा संक्षेपित किया जा सकता है, जो लीन विनिर्माण सिद्धांतों की अवधारणा के बहुत समीप हैं:[4]

    1. अपशिष्ट को निकालना
    2. सीखने का विस्तार करना
    3. यथासंभव देर से निर्णय लेना
    4. जितनी शीघ्र हो सके वितरण करना
    5. समूह को सशक्त बनाना
    6. अखंडता का निर्माण करना
    7. संपूर्ण को अनुकूलित करना

अपशिष्ट को समाप्त करना

लीन दर्शन ग्राहक के लिए मूल्य न बढ़ाने वाली प्रत्येक वस्तु को व्यर्थ (मुडा (जापानी शब्द)) मानता है। ऐसे अपशिष्ट में सम्मिलित हो सकते हैं:[5]

  1. आंशिक रूप से किया गया कार्य
  2. सॉफ़्टवेयर ब्लोट
  3. पुनः सीखना
  4. कार्य स्विचिंग (मनोविज्ञान)
  5. प्रतीक्षा
  6. हैंडऑफ़
  7. सॉफ़्टवेयर बग
  8. प्रबंध गतिविधियाँ

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

अपशिष्ट की पहचान करने के लिए मान स्ट्रीम मानचित्रण तकनीक का उपयोग किया जाता है। दूसरा कदम अपशिष्ट के स्रोतों को इंगित करना और उन्हें समाप्त करना है। अपशिष्ट-हटाना लगातार तब तक होना चाहिए जब तक कि आवश्यक प्रक्रियाएँ और प्रक्रियाएँ समाप्त न हो जाएँ।

सीखने को बढ़ाना

सॉफ़्टवेयर विकास कोड लिखते समय पुनरावृत्तियों पर आधारित एक सतत सीखने की प्रक्रिया है। सॉफ़्टवेयर डिज़ाइन एक समस्या-समाधान प्रक्रिया है जिसमें डेवलपर्स कोड लिखते हैं और उन्होंने क्या सीखा है। सॉफ़्टवेयर का मूल्य उपयोग के लिए उपयुक्तता में मापा जाता है न कि आवश्यकताओं के अनुरूप में।

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

सीखने की प्रक्रिया को छोटे पुनरावृत्ति चक्रों के उपयोग से तेज किया जाता है - प्रत्येक को रिफैक्टरिंग और एकीकरण परीक्षण के साथ जोड़ा जाता है। ग्राहकों के साथ लघु फीडबैक सत्रों के माध्यम से फीडबैक बढ़ाने से विकास के वर्तमान चरण को निर्धारित करने और भविष्य में सुधार के लिए प्रयासों को समायोजित करने में मदद मिलती है। उन छोटे सत्रों के दौरान, ग्राहक प्रतिनिधि और विकास समूह दोनों डोमेन समस्या के बारे में अधिक सीखते हैं और आगे के विकास के लिए संभावित समाधान ढूंढते हैं। इस प्रकार ग्राहक विकास प्रयासों के मौजूदा परिणाम के आधार पर अपनी जरूरतों को बेहतर ढंग से समझते हैं, और डेवलपर्स सीखते हैं कि उन जरूरतों को बेहतर ढंग से कैसे पूरा किया जाए। ग्राहक के साथ संचार और सीखने की प्रक्रिया में एक और विचार सेट-आधारित विकास है - यह भविष्य के समाधान की बाधाओं को संप्रेषित करने पर ध्यान केंद्रित करता है, न कि संभावित समाधानों पर, इस प्रकार ग्राहक के साथ वार्तालाप के माध्यम से समाधान के जन्म को बढ़ावा देता है।Template:Jargon-statement

यथासंभव देर से निर्णय लें

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

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

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

जितनी शीघ्र हो सके वितरित करना

तीव्र प्रौद्योगिकी विकास के युग में, यह सबसे बड़ा नहीं है, बल्कि सबसे तेज़ है। जितनी शीघ्र अंतिम उत्पाद बिना किसी बड़े दोष के वितरित किया जाएगा, उतनी ही शीघ्र प्रतिक्रिया प्राप्त की जा सकती है, और अगले पुनरावृत्ति में सम्मिलित किया जा सकता है। पुनरावृत्तियाँ जितनी छोटी होंगी, समूह के अंदर सीखना और संचार उतना ही बेहतर होगा। गति के साथ, निर्णयों में देरी हो सकती है। स्पीड ग्राहक की वर्तमान जरूरतों को पूरा करने का आश्वासन देती है, न कि वह जो उन्हें कल चाहिए थी। इससे उन्हें इस बारे में निर्णय लेने में देरी करने का अवसर मिलता है कि उन्हें वास्तव में क्या चाहिए जब तक कि वे बेहतर ज्ञान प्राप्त न कर लें। ग्राहक गुणवत्तापूर्ण (व्यावसायिक) उत्पाद की तीव्र डिलीवरी को महत्व देते हैं।

बिल्कुल समय पर (व्यवसाय)व्यवसाय) | जस्ट-इन-टाइम उत्पादन विचारधारा को सॉफ्टवेयर विकास में लागू किया जा सकता है, इसकी विशिष्ट आवश्यकताओं और वातावरण को पहचानते हुए। यह आवश्यक परिणाम प्रस्तुत करके और समूह को खुद को व्यवस्थित करने और एक विशिष्ट Iteration#Project प्रबंधन के लिए आवश्यक परिणाम को पूरा करने के लिए कार्यों को विभाजित करने की अनुमति देकर प्राप्त किया जाता है। शुरुआत में, ग्राहक आवश्यक इनपुट प्रदान करता है। इसे बस छोटे कार्ड या उपयोगकर्ता कहानी में प्रस्तुत किया जा सकता है - डेवलपर्स प्रत्येक कार्ड के कार्यान्वयन के लिए आवश्यक समय का अनुमान लगाते हैं। इस प्रकार कार्य संगठन कानबन कार्ड में बदल जाता है | स्व-खींचने वाली प्रणाली - प्रत्येक सुबह एक आमने - सामने की मीटिंग के दौरान, समूह का प्रत्येक सदस्य समीक्षा करता है कि कल क्या किया गया है, आज और कल क्या किया जाना है, और किसी भी आवश्यक इनपुट के लिए संकेत देता है सहकर्मियों या ग्राहक से. इसके लिए प्रक्रिया में पारदर्शिता की आवश्यकता है, जो समूह संचार के लिए भी फायदेमंद है।

इस सिद्धांत में अंतर्निहित मिथक यह है कि जल्दबाजी बर्बादी लाती है। हालाँकि, कम कार्यान्वयन से पता चला है कि आउटपुट को जल्द से जल्द देखने और उसका विश्लेषण करने के लिए तेजी से समूह करना एक अच्छा अभ्यास है।

समूह को सशक्त बनाएं

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

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

=== === में अखंडता बनाएं ग्राहक को सिस्टम का समग्र अनुभव होना आवश्यक है। यह तथाकथित कथित अखंडता है: इसका विज्ञापन, समूह, तैनाती, पहुंच कैसे की जा रही है, इसका उपयोग कितना सहज है, इसकी कीमत और यह समस्याओं को कितनी अच्छी तरह हल करता है।

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

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

संपूर्ण को अनुकूलित करना

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

ठोस, वास्तविक जीवन की स्थिति में लागू करने से पहले, किसी परियोजना के सभी सदस्यों द्वारा लीन सोच को अच्छी तरह से समझा जाना चाहिए। बड़ा सोचो, छोटे कार्य करो, शीघ्र असफल हो जाओ; तेजी से सीखें[8] - ये नारे क्षेत्र को समझने के महत्व और संपूर्ण सॉफ्टवेयर विकास प्रक्रिया में लीन सिद्धांतों को लागू करने की उपयुक्तता का सारांश देते हैं। केवल जब सभी सामान्य सिद्धांतों को एक साथ कार्यान्वित किया जाता है, कार्यकाजी माहौल के संबंध में मजबूत सामान्य ज्ञान के साथ जोड़ा जाता है, तो सॉफ्टवेयर विकास में सफलता का आधार होता है।

लीन सॉफ्टवेयर अभ्यास

लीन सॉफ़्टवेयर विकास पद्धतियाँ, या जिसे पोपेन्डिएक्स टूल कहते हैं, फुर्तीली सॉफ़्टवेयर विकास में मूल समकक्षों से थोड़ा सा पुनर्स्थापित किया गया है। ऐसी प्रथाओं के उदाप्रत्येकणों में सम्मिलित हैं:

चूंकि एजाइल सॉफ्टवेयर विकास एजाइल मेनिफेस्टो में व्यक्त मूल्यों और सिद्धांतों के आधार पर विधियों और प्रथाओं के एक सेट के लिए एक हाइपोनिमी और हाइपरनिमी है, इसलिए लीन सॉफ्टवेयर विकास को एक एजाइल सॉफ्टवेयर विकास विधि माना जाता है।[9]


यह भी देखें

संदर्भ

  1. ↑ 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.
  2. ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. ISBN 978-0-321-15078-3.
  3. ↑ Mary Poppendieck: "The role of leadership in software development" https://www.youtube.com/watch?v=ypEMdjslEOI
  4. ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 13–15. ISBN 978-0-321-15078-3.
  5. ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 19–22. ISBN 978-0-321-15078-3.
  6. ↑ "12 Principles Behind the Agile Manifesto - Agile Alliance". agilealliance.org. 4 November 2015.
  7. ↑ 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.
  8. ↑ Mary Poppendieck; Tom Poppendieck (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional. pp. 182–. ISBN 978-0-321-15078-3.
  9. ↑ "What is Agile Software Development?". agilealliance.org. 29 June 2015.


अग्रिम पठन

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=लीन_सॉफ्टवेयर_विकास&oldid=234000’