नियोजन पोकर और वर्डी डेवलपर्स [बंद]


10

मेरी टीम 4 डेवलपर्स से बना है; सभी अनुभवी और कुशल। उनमें से एक चिंताजनक, अच्छी तरह से अभिप्रेरित चेप है जो अपनी कहानियों के लिए तकनीकी समाधान को परिभाषित करने पर जोर देता है, इससे पहले कि हम नियोजन पोकर के साथ हमारे अनुमानों को नीचे रखें। वह अनुमान लगाने से इनकार करता है कि क्या उसके पास सहमत तकनीकी समाधान का कोई मोटा विचार नहीं है (जो उचित, सही लगता है?)।

समस्या यह है कि हमारे आकलन सत्र हमेशा के लिए खत्म हो रहे हैं !! अपने अनुभव में, नियोजन पोकर खेलते समय आप इस तरह के व्यक्तित्व से कैसे निपटते हैं?

जवाबों:


13

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

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


1
एक टाइमर एक महान विचार है। यह बोलने वालों को रसीला होने की याद दिलाता है और उन्हें इस बात पर ध्यान केंद्रित करने के लिए मजबूर करता है कि वे बहुत बुनियादी बिंदु पर क्या कहना चाहते हैं।
15:11 बजे शेन वीलटी

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

2
न केवल एक टाइमर एक अच्छा विचार है, मेरा मानना ​​है कि यह अनुशंसित है (शायद फुर्तीली योजना और अनुमान वाला कोई व्यक्ति इसकी पुष्टि कर सकता है)। मेरी समझ यह है कि अधिकांश गतिविधियों की तरह, पोकर सत्रों की योजना बनाना उन स्थितियों को रोकने के लिए समय-समय पर होना है, जैसे प्रश्न का जिक्र है।
थॉमस ओवेन्स

1
For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch- इसलिए चर्चा। फिर हर कोई इसके बारे में जानता है और अनुमान बेहतर है।
इज़्काता

3

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

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


2
+1, मैं एक विश्लेषक व्यक्तित्व हूं और इस समस्या से जूझ रहा हूं। मुझे लगता है कि मैं बहुत अधिक पूर्ण और पूर्ण हूं और मेरे साथियों की तुलना में कम कीड़े हैं, लेकिन मैं आसानी से सही जानकारी से कम स्थितियों के साथ बाहर और अप्रभावी हो जाता हूं। मैं कम तनावपूर्ण तरीके से अज्ञात के साथ प्रयास करने और निपटने के लिए हर रोज प्रयास करता हूं।
maple_shaft

2

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

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

नियोजन पोकर एक और त्रुटि पेश करता है: एक्स को पिन करने की कोशिश करने के बजाय, हम इसे एक असतत पैमाने पर मिलाते हैं, फिबोनाची स्केल (1, 2, 3, 5, 8, आदि) सबसे लोकप्रिय है। यह कह रहा है कि आकार उतना नहीं है जितना यह है। जब हम कहते हैं कि कहानी का आकार 3 अंक है, तो हम वास्तव में कहते हैं "यह एक्स प्लस-माइनस कुछ भिन्नता है और एक्स 3 से करीब है कि यह 2 या 5 है।"

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


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

10
"ऐसा लगता है कि आपका सहकर्मी अनुमान और प्रतिबद्धता के बीच अंतर को नहीं समझता है" मैं पूरी तरह से इस से संबंधित हो सकता हूं क्योंकि कई प्रबंधक आपके प्रारंभिक अनुमानों को ले जाएंगे और उन्हें प्रतिबद्धताओं में बदल देंगे । हम में से कुछ अपने आप को एक मोटा अनुमान देने के बारे में घबराए हुए हैं क्योंकि प्रबंधकों ने हमें उनके पास पकड़ लिया है और फिर हमें उम्मीद है कि लंबे समय तक काम करने के लिए बिना नींद के साथ इसे स्प्रिंट समय सीमा तक पूरा करना होगा।
maple_shaft

1
@maple_shaft: आप बिल्कुल सही हैं, अनुमान / प्रतिबद्धता हमारे उद्योग की सबसे बड़ी गलत धारणाओं में से एक है और यह गलत धारणा इसकी सबसे बड़ी बाधाओं में से एक है। आपकी "घबराहट", "लंबे सप्ताहांत", "नींद नहीं" आदि इसके परिणाम हैं। आप इस समस्या को तभी हल कर सकते हैं जब आप सभी को, अपनी पूरी टीम, अपने प्रबंधक आदि को शामिल करें। यही कारण है कि फुर्तीला संक्रमण इतना कठिन है। इन अवधारणाओं को समझे बिना कार्ड का डेक चुनना आसान है।
अज़ेगलोव

1
@azheglov, कभी कभी चंचल संक्रमण क्योंकि प्रबंधन मुश्किल है सोचता है कि वे चंचल चाहते है कि जब वास्तव में वे एक भयानक हीन भावना और के लिए एक मजबूत इच्छा के साथ सूक्ष्म प्रबंध megalomaniacs हैं कभी जब आवश्यकताओं परिवर्तन या नई जानकारी की खोज की है स्प्रिंट कार्यक्रम समायोजित करें। दूसरे शब्दों में, वे वास्तव में एजाइल नहीं चाहते हैं क्योंकि सच्चा एजाइल मौलिक रूप से उन सभी चीजों का विरोधाभासी है जो वे जानते हैं।
maple_shaft

@maple_shaft, आपको वह अधिकार भी मिल गया है! मैं उन सभी कारणों में नहीं जाऊँगा जिनकी वजह से मेरी टिप्पणी में
चुस्ती

1

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


1

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

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

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

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