'दो बार काम, आधा समय' कोड को क्रैक करने के लिए एक प्रोग्रामर गाइड

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

बीसवीं शताब्दी में प्रबंधन का सबसे महत्वपूर्ण, और वास्तव में अद्वितीय, योगदान विनिर्माण क्षेत्र में मैनुअल श्रमिकों की उत्पादकता में पचास गुना वृद्धि थी। इक्कीसवीं सदी में प्रबंधन को जो सबसे महत्वपूर्ण योगदान देने की जरूरत है, वह ज्ञान कार्य और ज्ञान कार्यकर्ता की उत्पादकता को बढ़ाना है।

21वीं सदी में बीस साल बाद, हम सॉफ्टवेयर विकास की दुनिया में इस महत्वाकांक्षी लक्ष्य को पूरा करने के कितने करीब हैं? मैं देख रहा हूं कि हम इससे बहुत दूर हैं। आइए देखें कि हम कहां हैं, हमें क्या समस्याएं हैं और हम उनके बारे में क्या कर सकते हैं।

सॉफ्टवेयर विकास दक्षता के व्यापक दृष्टिकोण की खोज

"द आर्ट ऑफ़ डूइंग ट्वाइस द वर्क इन हाफ़ द टाइम" इस फ्रेमवर्क के सह-लेखक जेफ़ सदरलैंड की " स्क्रम " पुस्तक का उपशीर्षक है। मुझे यह उपशीर्षक पसंद है, क्योंकि यह दृढ़ता से दर्शाता है कि हम अपने प्रोग्रामिंग प्रयासों में कितने अधिक कुशल बन सकते हैं। हालांकि यह सब बादल रहित नहीं है। पहली समस्या जिसका हम यहाँ सामना करते हैं वह यह है कि यह समझना कठिन है कि हमारे काम में दक्षता क्या है। निम्नलिखित जटिल समस्या यह समझ रही है कि क्या हम समय के साथ अधिक कुशल हो जाते हैं।

लेकिन हम आखिर में दक्षता क्यों चाहते हैं? ठीक है, यह कम प्रयास के साथ एक ही काम करने के बारे में है, और हमारे जीवन के कई क्षेत्रों में, समान या बेहतर परिणाम तेजी से या कम कीमत पर प्राप्त करना बहुत अच्छा है।

आइए अपने प्रश्न पर वापस आते हैं। स्क्रम व्यवसायी किसी कार्य के माप के रूप में कहानी बिंदुओं का प्रस्ताव करते हैं। Scrum.org वेबसाइट से एक परिभाषा है :

एक स्टोरी पॉइंट माप की एक सापेक्ष इकाई है, जिस पर निर्णय लिया जाता है और व्यक्तिगत स्क्रम टीमों द्वारा उपयोग किया जाता है, आवश्यकताओं को पूरा करने के प्रयास के सापेक्ष अनुमान प्रदान करने के लिए।

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

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

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

मापन की वस्तु को परिभाषित करना

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

मेरे वर्तमान स्थान पर, हम तीन अलग-अलग स्तरों का उपयोग करते हैं:

 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task).

हमें निम्नलिखित विशेषताओं के लिए समायोजन की आवश्यकता है:

1. शुरुआत का समय और पूरा होने का समय है;
2. नियमित रूप से होता है।

तो हम यहाँ परिभाषित करते हैं "काम का यह बड़ा टुकड़ा"। आइए इसे लेख के परिणामी भाग में कार्रवाई का नाम दें। सभी क्रियाएं समान नहीं होती हैं। मैंने ऊपर के उदाहरण में तीन प्रकार प्रदर्शित किए हैं।

हमें नियमित रूप से होने वाली कार्रवाई की आवश्यकता है।

यह आवश्यकता इस तथ्य से आती है कि आप शुरू से अंतत: कुशल नहीं हो सकते हैं लेकिन समय के साथ अधिक कुशल हो सकते हैं। यह वर्णित दृष्टिकोण की कमी नहीं है। स्क्रम इस तरह काम करता है, टोयोटा प्रोडक्शन सिस्टम इस तरह काम करता है, और विज्ञान इस तरह काम करता है। हमें वर्तमान स्थिति की खोज करने और इसे लगातार सुधारने के लिए दोहराने की आवश्यकता है।

आप केवल संयोग से ही अंततः अनुकूलित दक्षता के साथ कुछ भी नया कर सकते हैं। और क्रिया जितनी जटिल होगी, उतनी ही कम संभव होगी। पहले से तैयारी मदद कर सकती है। हालांकि, पहले से तैयार करने की क्षमता का मतलब है कि कार्रवाई या उसके उप-कार्य अतीत में हुए हैं, और उनके बारे में ज्ञान है। पूरी तरह से कुछ नया तैयार करने के लिए कुछ भी नहीं है। दूसरी ओर, हम शायद ही अपने जीवन में पूर्ण नवीनता पाते हैं। पिछले अनुभव का एक अंश हमेशा कभी अनुभव न होने वाली स्थितियों के लिए प्रासंगिक होता है।

संक्षेप में, हमारे पास मापने के सार के रूप में एक प्रकार की क्रिया है।

एक प्रकार की क्रिया को कैसे मापें?

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

• एक महाकाव्य को पूरा करने में कितना समय लगा?
• शुरुआत से लेकर पूरा होने तक हमें 39 दिन लगे।

प्रशंसनीय।

क्या कुछ और है जो हमें मिलता है?

हमारे कार्य की दूसरी आवश्यकता, नियमित घटना, हमें इतना कुछ देती है कि इस पर विश्वास करना कठिन है। सबसे पहले, हम एक तरह की क्रियाओं का प्रवाह प्राप्त करते हैं। यहाँ डैनियल वैकांती द्वारा "एक्शनेबलएजाइल मेट्रिक्स फॉर प्रेडिक्टेबिलिटी" पुस्तक से प्रवाह की परिभाषा दी गई है:

सीधे शब्दों में कहा जाए तो प्रवाह एक प्रक्रिया के माध्यम से ग्राहक मूल्य का संचलन और वितरण है।

दो टाइमस्टैम्प के लिए हमारी आवश्यकता, एक क्रिया की शुरुआत और समाप्ति, हमें नए मेट्रिक्स का एक अच्छा सेट देती है। यहाँ वे उसी पुस्तक से हैं:

वर्क इन प्रोग्रेस (किसी भी समय हम जिन आइटम्स पर काम कर रहे हैं), साइकिल टाइम (उनमें से प्रत्येक आइटम को हमारी प्रक्रिया के माध्यम से प्राप्त करने में कितना समय लगता है), और थ्रूपुट (उनमें से कितने आइटम प्रति यूनिट समय में पूरे होते हैं) ).

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

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

चित्र में, आप दाईं ओर 50%, 70%, 85% और 95% के साथ हस्ताक्षरित प्रतिशतक रेखाएँ भी देख सकते हैं। उनका क्या मतलब है? बाईं ओर दिन हैं। आप निम्न तरीके से 85% और 16 दिनों को पढ़ सकते हैं:

समीक्षाधीन अवधि में हमारे सिस्टम में आने वाले 85% आइटम को छोड़ने में 16 दिन या उससे कम समय लगा।

इस खंड में मैंने दूसरी बार "सिस्टम" शब्द का प्रयोग किया है। इसका क्या मतलब है? आइए इसे इस कहानी के लिए निम्नलिखित तरीके से परिभाषित करें:

सिस्टम कुछ ऐसा है जो एक तरह की क्रिया कर रहा है।

घरों के निर्माण प्रणाली में एक तरह की एक क्रिया ऊपर से उदाहरण के लिए घर बनाना है। एक किलोमीटर सड़क बनाना यहां एक क्रिया के रूप में नहीं गिना जाता है। यह एक अलग तरह की क्रिया और दूसरी व्यवस्था है। हालाँकि, कोई ठोस विभाजन नहीं है, लेकिन हम चाहते हैं कि हमारे घर एक जैसे हों, साथ ही ए/बी परीक्षणों के साथ दांतों की सफाई और सॉफ्टवेयर विकास भी हो। कुछ अलग पर्याप्त के लिए, हम एक और प्रणाली के साथ आ सकते हैं।

एक और महत्वपूर्ण लाभ

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

क्या इस तर्क में कुछ है जो हमें एक जाल में ले जाता है? आइए करीब से देखें।

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

आइए डोनाल्ड नुथ ( या टोनी होरे ) द्वारा प्रोग्रामिंग ज्ञान के निम्नलिखित अंश पर एक नज़र डालें:

सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है।

मुझे लगता है कि आप इससे मिल चुके हैं, जो आपको सॉफ्टवेयर विकास के शुरुआती चरणों में प्रदर्शन के बारे में नहीं सोचने के लिए कहता है। आपने इस ज्ञान को निम्न रूप में देखा होगा:

इसे काम करो, इसे ठीक करो, इसे तेज करो।

पुस्तकालयों की स्थापना के बारे में उदाहरण से पता चलता है कि कहावत कोड और कोडिंग टीम के लिए भी प्रासंगिक है! हम यहां किस रहस्य से मिलते हैं! यह कोई रहस्य नहीं बल्कि एक तंत्र की विशेषता है। कम से कम दो कारण हैं कि हमें पहले प्रयास के बाद एन्हांसमेंट में सीधे कूदने से बचना चाहिए।

एन्हांसमेंट में सीधे कूद न जाने का सांख्यिकीय कारण

एक प्रकार की प्रत्येक पूर्ण क्रिया की अपनी अवधि होती है। अवधि में दो भाग होते हैं: एक सामान्य कारणों से होता है और दूसरा विशेष कारणों से होता है।

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

विशेष होने की प्रकृति विशेष अवधि के कारणों की असंगत उपस्थिति की ओर ले जाती है। जो दिखाता है वह हमेशा हमारी कार्रवाई का मूल होता है, हमारे संवर्द्धन का फलदायी लक्ष्य।

बाधाओं का सिद्धांत वृद्धि में सीधे कूदने का कारण नहीं है

बाधाओं का सिद्धांत हमें क्या बताता है? यह हमें बताता है कि किसी वस्तु का संपूर्ण उत्पादन उतना ही उत्पादक होगा जितना कि उसका सबसे कम उत्पादक भाग। कल्पना कीजिए कि हमारी एक कंपनी छोटे-छोटे एक-मंज़िला घरों का निर्माण कर रही है। हमारी वार्षिक क्षमताएं निम्नलिखित हैं:

• 6 बेसमेंट,
• दीवारों के 24 सेट,
• 52 छतें।

हम प्रति वर्ष कितने घर बना सकते हैं? आप छह का उत्तर दे सकते हैं, लेकिन मेरा सुझाव है कि छह से अधिक न कहें। हमारी निर्माण प्रक्रिया एक परिणामी है: बेसमेंट → दीवारें → छत। अंतिम, छठा भाव वर्ष के अंत में समाप्त हो सकता है।

यदि हम अपने द्वारा बनाई गई दीवारों या छतों की संख्या में वृद्धि करते हैं, तो क्या इससे हमारी पूरी कंपनी की क्षमता बदल जाएगी? क्या हम उल्लिखित "छह से अधिक नहीं" से अधिक उत्पादन करेंगे? नहीं, बेसमेंट अभी भी हमें सीमित करता है।

ऊपर से क्षमता संख्याएँ इस सतही कंपनी के अनुभव से आती हैं। पहली उपयोगकर्ता कहानी को लागू करने के बाद हमारे पास यह अनुभव नहीं है। हमें अभी तक अपनी उपयोगकर्ता कहानियों के निर्माण प्रणाली की बाधा का निर्धारण करना है क्योंकि हम नहीं जानते कि प्रत्येक सबएक्शन कितने समय तक चलता है। हमारी उपयोगकर्ता कहानियों के विकास की प्रक्रिया के एक भाग के रूप में गुणवत्ता आश्वासन पर विचार करें। उपयोगकर्ता कहानी का परीक्षण चार घंटे तक चलता है। उपयोगकर्ता कहानी का विकास सामान्य रूप से पांच कार्य दिवसों तक चलता है। मान लीजिए कि एक वर्ष में 250 कार्य दिवस होते हैं। क्या आपको उम्मीद है कि इसके अंत में 50 उपयोगकर्ता कहानियां पूरी होंगी या 730? जैसा कि घरों और बेसमेंट के साथ होता है, अधिकतम 50 प्रति वर्ष। हमें अपनी कार्रवाई के आकार और उसके सबसे कम उत्पादक हिस्से को समझने के लिए आंकड़े इकट्ठा करने की जरूरत है।

संवर्द्धन शुरू करने के लिए कितने पूर्ण कार्य पर्याप्त हैं?

पूरी तरह सुनिश्चित होने के लिए, मेरा सुझाव है कि इस बिंदु पर ∞ पूर्ण क्रियाओं की संख्या हो। इस सटीक संख्या के होने के बाद, आप 100% सुनिश्चित हो सकते हैं कि पहले क्या बढ़ाना है।🥁

शुद्ध गणित की दुनिया से बाहर के लोगों के लिए, आइए निम्नलिखित विचारों पर विचार करें। यहाँ "एक्शनेबल एजाइल मेट्रिक्स फॉर प्रेडिक्टेबिलिटी " पुस्तक से एक संदर्भ दिया गया है, जिसमें " कुछ भी कैसे मापें " पुस्तक का संदर्भ दिया गया है:

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

कृपया इसे पहले पांच कार्यों के लिए कुछ बदलने की वर्जना के रूप में न देखें। अन्य पहलुओं पर भी विचार करें: स्वास्थ्य सुरक्षा, टीम सामंजस्य और बहुत कुछ।

एन्हांसमेंट कहां से शुरू करें?

यदि हम प्रारंभिक कार्रवाई करते हैं, उदाहरण के लिए, उस पर एक बटन दबाकर टीवी चालू करना, हम इसे समग्र रूप से सोच सकते हैं। आंदोलनों की संख्या और समग्र समय को कम करने के लिए, अपने लिए एक क्लिकर खरीदें और इसे अपने सोफे के पास एक जगह पर रखें। इस उदाहरण में, पहली कार्रवाई में लगभग 20 सेकंड लग सकते हैं और दूसरी... एक सेकंड। मेरी बधाई! आपने पहले आवश्यक समय का 95% कम कर दिया है और अभी भी वही मान प्राप्त कर रहे हैं। क्या शानदार अपशिष्ट उन्मूलन है!

सभी क्रियाएं इतनी सीधी नहीं होतीं। पहले से उल्लिखित उपयोगकर्ता कहानियों का विकास जटिल है। वहां के सुधार को एक छलांग में संभालना चुनौतीपूर्ण है। हमें चीजों को उप-क्रियाओं में तोड़ने की जरूरत है, जैसे घरों के निर्माण के उदाहरण में। हम निम्नलिखित जीवनचक्र से शुरू कर सकते हैं:

1. विश्लेषण,
2. विकास,
3. परिक्षण,
4. किया हुआ।

कहा से शुरुवात करे?

लीन मैन्युफैक्चरिंग में, निर्माण की प्रक्रिया, या इस आलेख में नामित कार्रवाई में तीन प्रकार के सब-एक्शन होते हैं:

• मूल्य वर्धित गतिविधियाँ;
• आवश्यक गैर-मूल्य वर्धित गतिविधियाँ;
• बेकार।

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

लीन मैन्युफैक्चरिंग में, अपशिष्ट (या मुडा ) को टोयोटा प्रोडक्शन सिस्टम निर्माता, ताइची ओहनो द्वारा जाना और परिभाषित किया जाता है। कम से कम वे कार निर्माता कंपनी टोयोटा के लिए परिभाषित हैं। अन्य उद्योगों के अपने संस्करण हैं। यहाँ हमारा है, " लीन सॉफ्टवेयर डेवलपमेंट " पुस्तक में मैरी और टॉम पोपेंडीक्स द्वारा बनाया गया:

1. आंशिक रूप से किया गया काम,
2. अतिरिक्त प्रक्रियाएं,
3. अतिरिक्त सुविधाएं,
4. कार्य बदलना,
5. इंतज़ार कर रही,
6. गति,
7. दोष के।

या ये? उन्हीं लेखकों की " इंप्लीमेंटिंग लीन सॉफ्टवेयर डेवलपमेंट " पुस्तक से:

1. आंशिक रूप से किया गया काम,
2. अतिरिक्त सुविधाएं,
3. फिर से सीखना,
4. अनावश्यक हैंडऑफ़,
5. कार्य बदलना,
6. देरी,
7. दोष के।

कम से कम सॉफ्टवेयर इंजीनियर तो अब जा सकते हैं!😅

हमारे उद्योग में इतने सालों में ये स्तंभ इतने कैसे बदल सकते हैं? मैं आने वाले सभी समय के लिए कचरे की पर्याप्त सूची होने की असंभवता में उत्तर देखता हूं। यहां तक कि टोयोटा, किसी समय आठवें कचरे के साथ आई थी।

यह बहुत अच्छी बात है कि हमारे उद्योग के लिए सूची इतनी मौलिक रूप से बदल गई है। यह परिवर्तन हमारे दिमाग को हमारे विचारों पर पुनर्विचार करने के लिए खोलता है जो लगातार व्यर्थ है। सॉफ्टवेयर विकास का बेकार हिस्सा क्या हो सकता है, इस पर एक और विचार यहां दिया गया है:

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

यह डेविड एंडरसन द्वारा मार्क मैककैन और माइकल ओ'रिली के साथ " द वैल्यू फ्लाईव्हील इफेक्ट " का एक उद्धरण है। वाह, क्या सवारी है!

तो, हम कैसे शुरू करें? कम से कम उत्पादक सबसेक्शन को देखकर। हम क्या खोजते हैं? सबएक्शन जो मूल्य नहीं जोड़ते हैं।

उपयोगकर्ता कहानियां विकास वर्कफ़्लो पर पुनर्विचार करना

मैं आपको उस कार्यप्रवाह की याद दिलाता हूं जो हमारे पास था:

1. विश्लेषण,
2. विकास,
3. परिक्षण,
4. किया हुआ।

आमतौर पर, ये अलग-अलग लोगों द्वारा किए गए भाग होते हैं, और हैंडऑफ़ के लिए प्रतीक्षा करने के लिए हमेशा कुछ समय होता है। आइए इसे दस्तावेज करें:

1. विश्लेषण सक्रिय,
2. विश्लेषण किया गया,
3. विकास सक्रिय,
4. विकास हो गया,
5. परिक्षण,
6. किया हुआ।

मैंने इन कदमों का आविष्कार नहीं किया। मैंने उन्हें ActionableAgile Analytics उत्पाद डेमो से लिया। क्या हम उन पर भरोसा कर सकते हैं? मैं हाँ कहूँगा, क्योंकि मैंने वास्तविक डेटा के विभिन्न उदाहरण देखे हैं, और यह एक नज़दीकी दिखता है। आइए निम्नलिखित चरणों के आँकड़ों की जाँच करें। यह औसत प्रदर्शित करता है।

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

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

खोजे गए समय की बर्बादी को संबोधित करना

चूंकि हमारे पास डेटा के प्रदर्शनात्मक सेट के बारे में बहुत कम जानकारी है, इसलिए विशिष्ट अनुशंसाएं नहीं होंगी जैसे: "टीम ई को बेहतर कंप्यूटर दें"। हालांकि, आपके मामले में खुद को प्रेरित करने के लिए पर्याप्त विचार होंगे। हमारी प्रक्रिया का सबसे कम उत्पादक हिस्सा विश्लेषण संपन्न चरण है। हम इसे इसलिए भी नहीं कह सकते क्योंकि यह प्रतीक्षा का वर्णन करता है। हालाँकि, यह प्रत्येक कार्य का लगभग 29% लेता है। यहाँ क्या कारण हो सकता है?

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

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

समाधान प्रस्तावित करने से पहले मूल-कारण विश्लेषण लागू करें: पाँच क्यों , मछली की हड्डी या कुछ और का उपयोग करें।

लागू परिवर्तन की सफलता का सत्यापन

मान लीजिए कि हमने पिछले अनुभाग से समस्या का समाधान किया है। हम कैसे सुनिश्चित हो सकते हैं कि प्रस्तावित परिवर्तन काम कर गया? हमें एक बार फिर डेटा जमा करने की जरूरत है। क्या आपको ऊपर से पांच का नियम याद है? हम इसे यहां भी इस्तेमाल कर सकते हैं। हमारा सिस्टम अब एडजस्ट हो गया है। आइए इसे फिर से मापें।

अपने काम में, मैं प्रयोग के परिणामों को मापने के लिए दो उपकरणों का उपयोग करता हूं:

1. संचयी प्रवाह आरेख,
2. साइकिल टाइम स्कैटरप्लॉट डायग्राम पर ट्रेंड लाइन।

क्या आप विश्लेषण के सियान क्षेत्र को देखते हैं? समय बीतने के साथ कम से कम पतले होने की अपेक्षा करें और अधिक से अधिक गायब हो जाएं।

इस पहले से परिचित आरेख पर दिखने वाली हरी धराशायी रेखा को देखें। यह पिछले एन दिनों के लिए 85% चक्र समय प्रवृत्ति दिखाता है। मैं एन के बजाय 30 का उपयोग करता हूं, क्योंकि यह परिवर्तनों को प्रदर्शित करने के लिए पर्याप्त स्थिर है। यदि खोजा गया समाधान पर्याप्त गहरे मूल कारण को संभालता है, तो उम्मीद करें कि यह लाइन ≈30% से 11 दिनों तक कम हो जाएगी।

यदि कोई महत्वपूर्ण डेटा परिवर्तन नहीं हैं, तो अन्य समाधानों की तलाश करने का समय आ गया है।

अगले चरण

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

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

सारांश में दृष्टिकोण

मान्य प्रश्न

मुझे लगता है कि बीसवीं सदी के योगदान प्रबंधन को करने में वर्णित दृष्टिकोण की उच्च क्षमता है। जब मैं किसी को विधि के बारे में बताता हूं, तो मुझे आमतौर पर कई प्रश्नों का सामना करना पड़ता है:

1. क्या यह प्रोग्रामिंग के आनंद को नष्ट नहीं कर देगा?

2. सॉफ्टवेयर विकास इतना अप्रत्याशित और इतना रचनात्मक है। हम इसकी दक्षता पर काम करने की बात कैसे कर सकते हैं?!

   
   

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

आपको पहले ऑनलाइन मोब प्रोग्रामिंग टूल की आवश्यकता क्यों होगी? तेज बनना है? लेकिन फिर तेज क्या था? आपको स्पष्ट सॉफ़्टवेयर डिज़ाइन चरण की आवश्यकता क्यों होगी? अहा! हमारी विकास टीम पर बगों का बोझ है, यही कारण है कि उपयोगकर्ता कहानियां बग को ठीक करने के लिए डेवलपर्स के लिए अपने जीवनचक्र का 30% तक इंतजार करती हैं। हम उन्हें क्यों नहीं रोकते?

प्रोग्रामिंग के आनंद को क्या मारता है कार्यों को पूरा करने के लिए अपने मांस को काटने की नियमित आवश्यकता है। बेहतर तरीकों, औजारों और ज्ञान से सशक्त होने से आनंद खत्म नहीं हो जाता।

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

क्या आपके तकनीकी, वास्तुकला और प्रक्रियात्मक ऋणों को संबोधित करने के लिए अंतत: एक आसान विकास प्रवाह की आवश्यकता एक बुलेटप्रूफ कारण नहीं है?

हां, यहां तक कि सबसे अधिक परिवर्तन-अनुकूल वास्तुकला में, ऐसे कठिन प्रश्न दिखाई देंगे, जिनकी आवश्यकता से अधिक समय की आवश्यकता होती है। और हमारे पास उन्हें संभालने के लिए पहले से ही 95 वीं प्रतिशतक रेखा के ऊपर साइकिल टाइम स्कैटरप्लॉट आरेख पर जगह है। लेकिन वे अपवाद हैं, और हम नहीं चाहते कि सब कुछ अपवाद बन जाए।

हम प्रबंधकों को आग बुझाने का काम नहीं करना चाहिए बल्कि अपने सिस्टम के डिजाइन और उनकी विविधता पर काम करना चाहिए।

स्पष्ट और गलत कदमों से बचना

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

शुरू करने के लिए जगह की खोज

एक सदी से भी पहले, फ्रेडरिक टेलर ने अपना काम उस पर शुरू किया जिसे अब हम वैज्ञानिक प्रबंधन के रूप में जानते हैं। उन्होंने अपने सहयोगियों को देखा और उनके लिए अपना काम करने के लिए अधिक कुशल तरीकों की खोज की:

टेलर वैज्ञानिक तरीकों से यह पता लगाने के लिए दृढ़ संकल्पित था कि प्रत्येक दिए गए कार्य को पूरा करने में पुरुषों को कितना समय लगना चाहिए; और यह 1882 के पतन में था कि उन्होंने वैज्ञानिक प्रबंधन की पहली विशेषताओं को क्रियान्वित करना शुरू किया।

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

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