नियोजन पोकर: डेवलपर की पहली छाप पर नोट्स

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


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

योजना पोकर बैठकों की आवृत्ति

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

किन टीमों के लिए प्लानिंग पोकर का इस्तेमाल करना फायदेमंद होगा

विचाराधीन टीम चिकित्सा उपकरणों के लिए सॉफ्टवेयर के सॉफ्टवेयर भाग और संबंधित हार्डवेयर भाग - फर्मवेयर के लिए सॉफ्टवेयर दोनों विकसित कर रही है। इसलिए, इस तरह के सत्र टीम के अधिकांश सदस्यों के लिए जानकारीपूर्ण होंगे, क्योंकि कोई केवल एक भाग के साथ काम करता है और सॉफ्टवेयर के अन्य भागों में वर्णित विवरण और कठिनाइयों को नहीं जानता है। रैली के दौरान, सबसे कम और उच्चतम रेटिंग वाले लोगों के बीच कई चर्चाएं शुरू हुईं: "यह करना आसान है।" हां, कभी-कभी अनुभवी प्रोग्रामर कम रेटिंग देते हैं, और कुछ मामलों में कम रेटिंग अनुभवहीनता द्वारा दी जाती है, क्योंकि यह हार्डवेयर के एक नियमित टुकड़े के लिए " व्यंग्य" फर्मवेयर है, और इतने लंबे समय तक परेशान क्यों </ sarcasm> ।

बड़े कार्यों को तोड़ दिया जाता है और व्यक्तिगत रूप से मूल्यांकन किया जाता है

अधिकांश कार्यों में परियोजना की बारीकियों के आधार पर कम से कम 3 भाग शामिल थे: सॉफ्टवेयर, फर्मवेयर, और वास्तव में परीक्षण। घटक तत्वों के समूह से जटिल प्रणालियों के लिए, एक तत्व के लिए एक आकलन किया गया था।

आप किसी अन्य परियोजना में भाग लेने के लिए किसी को आमंत्रित कर सकते हैं

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

पोकर सत्रों की योजना बनाने के लिए आवश्यक समय

ऐसे सत्रों के लिए बहुत समय की आवश्यकता होती है। प्रत्येक मुद्दे के लिए चर्चा का समय आवश्यकताओं की पूर्णता और समस्या के समाधान की समझ पर निर्भर करता है। मुद्दे की चर्चा का समय 5 से 30 मिनट तक भिन्न हो सकता है। इसलिए मैंने कार्यों के बैकलॉग भाग के अंतिम तीसरे भाग पर चर्चा की। इसमें डेढ़ घंटा लगा।

इसलिए संक्षेप में।

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