"स्वीमिंग" क्या है?


42

मैंने सुना है कि चंचल या चरम प्रोग्रामिंग के संदर्भ में झुंड का उल्लेख किया गया है। यह बाँधना का पूरक प्रतीत होता है।

वास्तव में क्या है? इसे कब लागू किया जाना चाहिए? आप इसे अच्छी तरह से कैसे करते हैं?


@ कोडकोड: Google पर मेरी खोजों ने कुछ प्रासंगिक परिणामों का उत्पादन किया, और मेरे प्रश्न के स्पष्ट उत्तर के साथ कोई भी नहीं। अगर वहाँ एक विहित जवाब है, तो हर तरह से, इसे यहाँ पोस्ट करें।
Jay Bazuzi


रणनीति वीडियो गेम "स्वॉर्ड ऑफ़ द स्टार्स" में एक वॉयसओवर लाइन है, जहां चींटी / मंटिस / हाइवमाइंड लोग आपको एक रिसर्च कमांड जारी करते हुए कहते हैं, "हम लैब को आपकी महिमा समझ रहे हैं।" मैंने हमेशा यह माना कि नाटकीय विडंबना के साथ उतरने का इरादा था।
एरिक रेपेन

जवाबों:


43

विचार यह है कि आपकी टीम में हर कोई एक ही समय में एक ही कहानी पर काम करता है। हर कोई अलग-अलग कार्यों पर ध्यान केंद्रित करने के बजाय, एक समय में एक कार्य को पूरा करने पर ध्यान केंद्रित करता है। फिर वे अगली चीज़ की ओर बढ़ते हैं, जहाँ वे सभी इस पर एक साथ काम करते हैं।

यह स्प्रिंट के अंत से पहले कहानियों को पूरा करने में संघर्ष करने वाली टीमों की मदद करता है। अक्सर टीम सभी कहानियों का 80% हिस्सा पूरा करती है, लेकिन कोई भी पूरा नहीं होता है। यह 80% कहानियों को पूरी तरह से समाप्त करने की तुलना में कम उपयोगी है, क्योंकि अधूरी कहानियों का अंत उपयोगकर्ता के लिए कोई प्रभावी मूल्य नहीं है। जब टीम के सभी लोग एक समय में एक कहानी पर ध्यान केंद्रित कर रहे हों तो कहानियों को पूरा करना आसान हो जाता है। यह स्वीमिंग के पीछे की प्रेरणा है।

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


+1। दिलचस्प। क्या आपने इस कार्य को अभ्यास में देखा है?
कोडार्ट

2
यह कहने का एक और तरीका है "जितना संभव हो उतना कम कार्य-प्रगति है", है ना?
जय बज्जुइ

1
@CodeWorks हाँ। हमने इसका उपयोग किया है जहां मैं वर्तमान में कुछ सफलता के लिए काम करता हूं। यह विकसित करने के लिए एक बहुत ही मजेदार तरीका है, क्योंकि यह सुविधा उन्मुख है। हर कोई एक ही समय में एक ही लक्ष्य की ओर काम कर रहा है, इसलिए मैंने पाया कि यह टीमवर्क को अच्छी तरह से बढ़ावा देता है।
ओलेक्सी

1
@JayBazuzi हाँ, बहुत ज्यादा। हालांकि टीम का पूर्ण समर्थन होना भी महत्वपूर्ण है।
ओलेक्सी

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

10

झुंड सिर्फ इस तथ्य को संदर्भित करता है कि एक कार्य या कहानी को पूरा करने के लिए कई लोग एक साथ काम करते हैं। मेरे अनुभव में यह कुछ ऐसा नहीं है जो आप अक्सर करते हैं।

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

हमारे पास हाल ही में बहुत कम कहानियाँ थीं जो कुछ काफी उबाऊ, निर्बाध काम थीं। मैंने टीम को काम खत्म करने के लिए एक छोटा प्रोत्साहन (पिज्जा) और समय सीमा (दिन के अंत) दिया, इसलिए उन्होंने कहानी पर झपट्टा मारा और एक दोपहर में कम से कम एक दो दिन का काम खत्म कर दिया। उन्हें काम जल्दी मिल गया और जल्दी निकल गया, फिर टीम का प्रत्येक सदस्य जो भी काम कर रहा था, उसमें वापस चला गया। उन्हें मुफ्त में दोपहर का भोजन मिला, मुझे जल्दी काम मिल गया जो सुस्त प्रकृति के कारण घसीटा जा सकता था, और टीम उनके स्प्रिंट से आगे निकल गई। जीत-जीतने के लिए।

"स्वीमिंग" "हे, चलो हम आपकी मदद करते हैं" के लिए एक फैंसी शब्द से ज्यादा कुछ नहीं है।


यह दूसरे जवाब से काफी अलग लगता है। आप कह रहे हैं "जब कोई असामान्य, तत्काल आवश्यकता हो, तो उस पर सभी को ले जाएं"। @ ओलेक्सी ने कहा "जब एक विकास चक्र की योजना बना रहे हों, तो एक समय में सभी को एक काम पर रखना बेहतर होगा, ताकि प्रत्येक व्यक्ति समानांतर में एक अलग कार्य कर सके।" या तो परिभाषा प्रशंसनीय है, और दोनों उपयोगी प्रथाएं हैं, लेकिन उनके पास 4x वोट हैं, इसलिए मैं मान रहा हूं कि उनका जवाब सबसे व्यापक रूप से स्वीकृत परिभाषा को दर्शाता है।
Jay Bazuzi

@ जय बज़ु: हर किसी को स्प्रिंट प्लानिंग के हिस्से के रूप में एक ही काम में लगाया जाता है, या चाहे यह ऑर्गनाइज़ली होता हो, जैसे की जरूरत होती है, परिभाषा अभी भी बहुत अधिक है - हर कोई एक ही काम पर एक साथ काम करता है।
ब्रायन ओकले

मुझे लगता है कि आपका उत्तर यहाँ बहुत महत्वपूर्ण है। अन्य उत्तर जो 'स्वीकृत' है, वह "क्या" है। लेकिन तुम्हारा पता कैसे लगता है।
एप-इनोगो

2

झुंड वास्तव में चपलता के लिए एक केंद्रीय अवधारणा है। यह कुछ ऐसा नहीं है जो "जब समस्याएं होती हैं" किया जाता है। झुंड, अपने सरलतम रूप में, का अर्थ है कि टीम आइटम (कहानियों) पर सहयोगात्मक रूप से काम करती है और उन्हें पूरा करने के लिए काम करती है। मुख्य अवधारणा "शुरू करना, और खत्म करना शुरू करना" है। दूसरे शब्दों में, एक कहानी पर स्वतंत्र रूप से काम करने वाले प्रत्येक डेवलपर के बजाय, टीम एक साथ कहानियों / कार्यों के अधिक सीमित सेट पर ध्यान केंद्रित करती है और प्रत्येक आइटम को जल्द ही पूरा करती है। इसे सिंगल-थ्रेडेड सिस्टम और मल्टी-थ्रेडेड के बीच के अंतर के रूप में सोचें। यदि किसी उपयोगकर्ता की कहानी में 10 कार्य हैं, और प्रत्येक को 8 घंटे का समय लगता है, तो यह मानते हुए कि कोई जटिलता नहीं थी, एक डेवलपर प्रत्येक कार्य को क्रमिक रूप से कार्य कर सकता है और कहानी को 80 घंटों में पूरा कर सकता है, या लगभग दो सप्ताह (10 दिन का स्प्रिंट दिया जा सकता है) प्रति दिन 8 घंटे)। क्या होगा यदि दो डेवलपर्स कार्यों को विभाजित करते हैं और उन्हें समवर्ती रूप से काम करते हैं? वही 80 घंटे का काम इस तरह से एक सप्ताह में पूरा किया जा सकता है। तीसरा जोड़ें, और आप देख सकते हैं कि यह अब 3 से 4 दिनों में हो सकता है।

स्वीमिंग कई तरीकों से की जा सकती है:

  1. जोड़ी प्रोग्रामिंग (कोड पर काम करने के लिए अगल-बगल बैठे दो डेवलपर्स, एक "ड्राइवर" है जो कोड लिख रहा है, दूसरा नाविक है, लंबी अवधि की दिशा को ध्यान में रखते हुए और साथ में कोड की समीक्षा करने में मदद करता है।
    1. जोड़ी का काम: एक डेवलपर और एक परीक्षक एक ही काम पर एक साथ काम करते हैं, एक कोडिंग और दूसरे परीक्षण, लेखन स्वचालन, आदि
    2. जैसा कि मैंने ऊपर बताया है कि झुंड, जो बहुत आम है। आमतौर पर, टीम के सदस्य एक कहानी को झुंड लेते हैं, लेकिन प्रत्येक इस पद्धति में अलग-अलग कार्यों का मालिक होता है।
    3. मॉब प्रोग्रामिंग: एक समय में पूरी टीम एक कहानी (या यहां तक ​​कि कार्य) पर केंद्रित है।

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

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


1

InfoQ के निम्नलिखित लेख में झुंड के लिए एक दृष्टिकोण का वर्णन किया गया है:

  • टीम इसके अधिकांश कोडिंग कार्यों के लिए भीड़ प्रोग्रामिंग का उपयोग करती है
  • टीम या व्यक्तिगत टीम के सदस्यों का एक हिस्सा अक्सर विभाजित होता है और कम अंतराल में टीम में शामिल होता है
  • हर कोई सब कुछ करता है (कोई भूमिका नहीं)
  • टीम अनुमानों का उपयोग नहीं कर रही है, WIP हमेशा एक है, स्टैंडअप या समान समारोहों की कोई आवश्यकता नहीं है

विस्तृत विवरण के लिए लेख पढ़ें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.