लीन सॉफ्टवेयर विकास

Not to be confused with Lean (proof assistant).

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

उत्पत्ति

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

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

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

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

अपशिष्ट को खत्म करें

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

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

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

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

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

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

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

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

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

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

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

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

जितनी जल्दी हो सके वितरित करें

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

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

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

टीम को सशक्त बनाएं

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

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

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

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

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

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

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

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

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

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

• मुदा देखना (जापानी शब्द)
• मान स्ट्रीम मानचित्रण
• बाधाओं का सिद्धांत|सेट-आधारित विकास
• कानबन कार्ड
• कतारबद्ध सिद्धांत
• प्रेरणा
• माप
• परीक्षण संचालित विकास

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

यह भी देखें

• चरम कार्यक्रम
• डेवऑप्स
• कानबन (विकास)
• कानबन बोर्ड
• दुबला एकीकरण
• लीन सेवाएं
• स्क्रम (विकास)

अग्रिम पठन

• 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.