चुस्त होने का क्या मतलब है?


17

हमारे पास एक परियोजना है जो हर कोई कहता है कि हम एक चुस्त तरीके से करेंगे लेकिन मुझे संदेह है कि हम स्पष्ट रूप से समझ चुके हैं कि चुस्त क्या है।

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

डेवलपर्स ने मुश्किल से एक दूसरे से बात की और विकास में कोई टीडीडी शामिल नहीं था। वास्तव में अधिकांश डेवलपर्स के पास शुरुआत में एक युक्ति थी और बस 2 या 3 सप्ताह के लिए इसके साथ स्प्रिंट की व्यवस्था की गई थी। क्लाइंट / स्टेक होल्डर के साथ शायद ही कोई संवाद था।

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

इसलिए मेरा सवाल यह है कि हम कहां गलत हो गए और मैं टीम को वही गलतियां करने से कैसे रोक सकता हूं।


4
प्रोग्रामर की एक डुप्लिकेट की तरह लगता है
।stackexchange.com

1
हां मैं आपसे 100% सहमत हूं। मेरे प्रबंधक ने चुस्त पर एक किताब पढ़ी और बस उस पर (हालांकि बहुत बुरी तरह से) उसके साथ हो गया। मैंने प्रोजेक्ट के सर्वर साइड पर टीडीडी का उपयोग किया लेकिन अन्य लोग इसे सीखना नहीं चाहते थे और न ही इसका लाभ देखना चाहते थे। हमारे पास एक फ्रेमवर्क था (क्लाइंट की तरफ) जो हमेशा के लिए ले लिया गया और डेवलपर यह तर्क देता रहा कि उसे सिर्फ इसके साथ (बिना किसी बाधा के) मिलने की जरूरत है।
JD01

3
हालांकि शीर्षक एक डुप्लिकेट लगता है, मुझे लगता है कि यह सवाल अपने आप में मददगार है क्योंकि कई टीमें "जेनेरिक" स्पष्टीकरण पढ़ती हैं कि फुर्तीली क्या है (और प्रशिक्षण कक्षाएं भी लेती हैं और सलाहकारों को किराए पर लेती हैं) और फिर JD01 के समान मुद्दों पर चलती हैं वैसे भी टीम। इस प्रश्न को इस विशिष्ट टीम के संदर्भ में रखने के लिए, विशिष्ट समस्याओं और समाधानों पर प्रकाश डाला जा सकता है, जो अन्य सामान्य पोस्ट प्रश्नों को संबोधित नहीं करेंगे।
DXM

जवाबों:


27

आप जो वर्णन कर रहे हैं वह एजाइल नहीं है (एजाइल मेनिफेस्टो) यह दैनिक स्थिति बैठकों के साथ झरना है। एजाइल का अर्थ है आसानी से बदलना, अगर उत्पाद के मालिक और इस तरह ग्राहकों के साथ कोई इंटरैक्टिव फीडबैक लूप नहीं है, तो क्या परिवर्तन हो रहा है?

एजाइल उत्पाद स्वामी / ग्राहकों के साथ निरंतर संचार के माध्यम से, तेजी से विफलताओं के बारे में है। बाद में जल्द से जल्द असफल होना बेहतर है, कम काम किया जाता है, और कम "खो" जाता है। और आप इस तर्क से नहीं फंसते हैं, कि "हमारे पास इसे सही तरीके से करने का समय नहीं है, क्योंकि हमने इसे गलत करने में इतना समय बिताया है, हमें बस इसी रास्ते पर चलते रहने की आवश्यकता है, भले ही यह विफलता की ओर ले जाए "।

ऐसा लगता है जैसे आपका प्रबंधन "SCRUM, लेकिन ..." जहां "लेकिन" है, जहां वे सभी SCRUM सामान बाहर फेंक देते हैं, जिन्हें वे समझ नहीं पाते हैं या उनसे सहमत नहीं होते हैं और बस चीजों को हमेशा की तरह उसी तरह से बेतरतीब जलप्रपात करते हैं, लेकिन यह सब करने के लिए नए चमकदार buzzword नामों के साथ।

SCRUM में दैनिक स्टैंड अप प्रबंधन को स्थिति प्रदान करने के बारे में नहीं है , यह डेवलपर इंटरैक्शन को बाध्य करने के लिए है, इसलिए आप जानते हैं कि आपके साथी टीम के सदस्य क्या कर रहे हैं और एक दूसरे की मदद कर सकते हैं और डुप्लिकेट काम नहीं कर सकते। यदि यह प्रति व्यक्ति 45 सेकंड से अधिक समय लेता है तो आप इसे गलत कर रहे हैं। यह टीम के लिए पारदर्शिता के बारे में है, अगर कोई व्यक्ति एक ही स्थिति को कई दिनों में दे रहा है, जो एक दिन के काम के लायक होनी चाहिए, तो टीम बाद में की तुलना में जल्द ही लोगों की समस्या को हल कर सकती है।

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

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


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

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

2
मैंने बहुत सारे TDD करना शुरू कर दिया था, लेकिन अब BDD पर स्विच कर दिया है, जो ग्राहकों के साथ संरेखण में अधिक है, स्वीकृति परीक्षणों के रूप में आवश्यक है। हालांकि मुझे लगता है कि TDD ने डिजाइन तैयार करने में मदद की जो मैंने परीक्षण प्रदान करने के अलावा नहीं देखी होगी।
JD01

1
टीडीडी के लिए महत्वपूर्ण कारण तकनीकी ऋण के संचय की दर को कम करते हुए, निरंतर रिफैक्टिंग की अनुमति देना है। यदि कोड है तो आप बदलने से डरते हैं क्योंकि रिटायरिंग बहुत महंगा होगा, परियोजना समय से पहले समाप्त हो जाएगी।
केविन क्लाइन

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

9

जारोद ने एक अच्छा उत्तर दिया (उस पर +1) और मैं उस पर थोड़ा विस्तार करना चाहूंगा।

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

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

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

इसमें थोड़ा समय लग सकता है, लेकिन ...

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

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

समझने की कुंजी यह है कि चुस्त चीजों को करने के लिए एक नई प्रक्रिया के साथ आने के बारे में नहीं है; यह मौजूदा प्रक्रियाओं / प्रथाओं के निरंतर परिवर्तन और निरंतर समायोजन के बारे में है।


1
downvoter करने के लिए: विस्तृत देखभाल करने के लिए? क्या मैंने कुछ पंखों को रगड़ दिया क्योंकि मैंने कहा कि नेत्रहीन स्क्रेम को नहीं अपनाएं या यह कुछ और था?
DXM

2
हाँ मूर्खतापूर्ण। मैं आपकी विस्तृत जानकारी के लिए +1 करूंगा।
माइकल डुरंट

1
+1 के लिए " समझने की कुंजी यह है कि चुस्त चीजें करने के लिए एक नई प्रक्रिया के साथ आने के बारे में नहीं है; यह मौजूदा प्रक्रियाओं / प्रथाओं के लिए निरंतर परिवर्तन और निरंतर समायोजन के बारे में है। "
डेविड 'गंजा अदरक'

-2

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

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


2
मैं निराश हो गया क्योंकि मुझे नहीं लगता कि यह मूल प्रश्न का उत्तर देता है।
ब्रायन ओकले

1
काफी, मुझे लगता है। मैं ओपी के प्रारंभिक आधार को संबोधित कर रहा था: "हमारे पास एक परियोजना है जो हर कोई कहता है कि हम एक चुस्त तरीके से करेंगे लेकिन मुझे संदेह है कि हम स्पष्ट रूप से समझ चुके हैं कि चुस्त क्या है।" बहुत से लोग कहते हैं कि वे हैं, या वे चाहते हैं कि "फुर्तीली" या "चुस्त रहें" यह समझे बिना कि फुर्तीला दर्शन या तरीके जो वास्तव में इसका समर्थन करते हैं।
स्टीवन वी

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

1
अपने उत्तर पर फिर से जाकर, मैं ऊपर दिए गए S.Robins से सहमत हूं और यह दर्शाने के लिए अपने उत्तर को संशोधित किया है।
स्टीवनवी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.