क्या कोई भी चुस्त प्रबंधन प्रथाओं के लिए कानबान (या स्क्रंबन) का उपयोग कर रहा है? कानबान के साथ आपका अनुभव क्या है? यह झरना परियोजनाओं पर निर्भरताओं के साथ बड़े जटिल वातावरण में कैसे काम करता है?क्या कोई कानबान का उपयोग कर रहा है?
मुझे पता है कि बीबीसी इसे काफी व्यापक रूप से उपयोग करता है। अधिक जानकारी के लिए डेविड जॉयस का ब्लॉग देखें http://leanandkanban.wordpress.com/
उसके पास आगे बढ़ने के लिए एक बहुत भारी स्लाइड डेक है।
मुझे लगता है कि दुबला सोच के बारे में याद रखने की बात यह है कि आपको पूरी तरह से मूल्य स्ट्रीम पर विचार करना चाहिए। जबकि आप कानबान जैसे तकनीकों का उपयोग करके विकास टीम को सुपर अनुकूलित कर सकते हैं, पुरस्कारों को पूरी तरह से प्राप्त करने के लिए दोनों स्ट्रीम (प्रबंधन/विश्लेषण) और डाउनस्ट्रीम (क्यूए/तैनाती/समर्थन) को शामिल करना अधिक महत्वपूर्ण है।
इसलिए, यह पूछने के लिए कि यह झरना या जटिल प्रक्रिया (आपके व्यक्तिगत प्रभाव से परे) में कैसे फिट है, यह बिल्कुल सही सवाल नहीं है। यह पूछना एक और महत्वपूर्ण सवाल है कि मैं पूरी मूल्य धारा को कैसे प्रभावित कर सकता हूं। मुझे पता है कि यह धार्मिक दुबला zealotry की शुरुआत की तरह लगता है, लेकिन इस तरह आप एक दुबला प्रक्रिया के असली मूल्य का एहसास होगा।
उदाहरण के लिए, एक विशिष्ट परियोजना के लिए इस परिदृश्य पर विचार:
कुल: 43 महीने
यदि विकास प्रक्रिया में दुबला लगाने से आप 100% तक सुधार करते हैं, यानी 4.5 महीने का विकास समय, 38.5 महीने का नया कुल लाता है। आपने केवल कुल मूल्य धारा में केवल 10% की वृद्धि की है ... महत्वहीन !!
आपको लड़ाई लड़ने और ऊपरी प्रबंधन के लिए लीन सोचने की शुरुआत करने की आवश्यकता है और यह दर्शाता है कि वास्तविक सफलता कहां है ... जो पूरी प्रक्रिया के पुन: डिजाइन में है।
याद रखें कि दुबला विकास प्रक्रिया नहीं है, इसे व्यवसाय के हर पहलू पर लागू किया जा सकता है।
विकास चर्चा से परे इस चर्चा को कैसे लेना है इस बारे में कुछ रोचक किताबें शामिल हैं;
सबसे पहले, यह समस्या है कि सॉफ्टवेयर के विकास में Kanban हल करने के लिए कोशिश करता है महसूस करने के लिए महत्वपूर्ण है: काम की
अधिकतर, अन्य चुस्त प्रथाएं विभिन्न तकनीकों के साथ समान समस्याओं को हल करने का भी प्रयास करती हैं। झरना परियोजनाओं पर निर्भरता के साथ
बड़ी जटिल वातावरण यदि आप एक परियोजना है कि पालन नहीं करता है चुस्त के रूप में तो अपने इनपुट कतार उम्मीद के मुताबिक नहीं होगा पर एक निर्भरता
यह यह मुश्किल बना देता है। यदि एक गैर-फुर्तीली परियोजना आपके ऊपर निर्भर करती है, तो समस्या कम हो सकती है - लेकिन आप उपभोग किए जाने से अधिक उत्पादन कर सकते हैं (दुबला शब्दावली में 'मुदा')। तो, आदर्श रूप से आप सभी आश्रित परियोजनाओं को कम से कम कुछ चुस्त प्रथाओं के बाद चाहते हैं, अगर कन्नबान स्वयं नहीं हैं।
कानबान, फ्लो और कैडेंस पर एक अच्छा लेख here पाया जा सकता है।
क्या कोई भी चुस्त प्रबंधन प्रथाओं के लिए कानबान (या स्क्रंबन) का उपयोग कर रहा है?
हाँ, मैं उपयोग कर रहा हूँ :-)
कैसे यह झरना परियोजनाओं पर निर्भरता के साथ बड़े जटिल वातावरण में काम करता है?
हमारे पर्यावरण में हमारे पास 500 डेवलपर हैं, इसलिए यह काफी बड़ा है। मेरी टीम पहली थी, जो मुख्य रूप से रखरखाव के काम के लिए कानबान का इस्तेमाल करती थी, और अब विकास के लिए। हमारा दैनिक काम बहुत कठिन था, क्योंकि अन्य निर्भर टीमों ने क्लासिक विकास और प्रबंधन तकनीकों का पालन किया था, और उन्हें पसंद आया (वे अभी भी करते हैं) पुश काम और कानबान लगभग पुल खींचते हैं।
हमारा दृष्टिकोण जितना संभव हो सके संवाद करना हमारे काम को पारदर्शी बनाना था, लेकिन पर्यावरण की अनिच्छा के कारण हम अपने आंतरिक कार्य पर ध्यान केंद्रित कर रहे थे। डब्ल्यूआईपी सीमा ने हमें ध्यान केंद्रित करने में मदद की, और दृश्य वर्कफ़्लो के साथ हम जानते थे कि इस समय कौन कर रहा है।
कानबान से पहले हमारा थ्रूपुट 9 0% था (दूसरे शब्दों में, जब 10 आइटम आए, तो हमने केवल 9 वितरित किए), और कानबान के बाद हमारे पास 100.4% था और यह बढ़ रहा था। एक अतिरिक्त परिणाम के रूप में, अन्य टीमों ने कानबान के बारे में पूछना शुरू कर दिया, क्योंकि उन्हें हमारे परिणाम पसंद आए, और अपने स्वयं के कानबान प्रणाली को लागू करना चाहते थे। फिलहाल मुझे 5 टीमों के बारे में पता है, जिन्होंने हमारे संगठन में कानबान शुरू किया था।
HTH,
ज़ोल्ट
तब से Kanban पुस्तक डेविड एंडरसन द्वारा प्रकाशित किया गया है, भी – Ingvald