क्या एक स्क्रैम टीम में कई भूमिकाओं वाले लोगों का होना ठीक है?


9

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

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

पहली चीजें पहले, कुछ मानकों और प्रथाओं को लागू करने के लिए विचार करने के लिए एक स्क्रैम शैली कुछ है? पढ़ने से, स्क्रम थोड़ा अधिक विश्वास और संचार पर भरोसा करने लगता है और विकास की तुलना में परियोजना प्रबंधन पर अधिक ध्यान केंद्रित करता है, जो कुछ ऐसा है जिससे हम पूरी तरह से रहित हैं क्योंकि हमारे पास वर्तमान में परियोजना प्रबंधन का कोई सादृश्य नहीं है।

दूसरा, अगर यह काम कर सकता है तो क्या यह किसी के लिए अनुचित है, चलो खुद कहते हैं, स्क्रेममास्टर और एक डेवलपर दोनों के रूप में कार्य करने के लिए? या एक डेवलपर के लिए भी उत्पाद स्वामी होना चाहिए (हालांकि संभावना है कि यह सीआईओ होगा, जो डेवलपर नहीं है)? मुझे पता है कि स्क्रैम मास्टर और प्रोडक्ट ओनर अलग-अलग लोग होने चाहिए, लेकिन साथ ही मुझे नहीं लगता कि हमारे पास कोई ऐसा व्यक्ति है जिसके पास प्रोडक्ट ओनर का गुण है (संभावना है कि यह "इन सभी कहानियों की जरूरत है" परवाह नहीं है लेकिन यह कैसे किया जाता है "सौदा के प्रकार और / या किसी भी फ्रीज एक whim पर unfrozen होगा)।

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


2
एक ही पृष्ठ पर रहने के लिए CIO के साथ सभी निजी सत्रों पर चर्चा करने के लिए स्टैंड-अप मीटिंग करने वाली आपकी टीम के साथ शुरू करें। अपने स्प्रिंट को बीच में लाने से रोकने के साथ शुभकामनाएं।
जेएफओ

जवाबों:


13

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

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

आप एक जटिल सुविधा के आसपास एक मिनी परियोजना का आयोजन कर सकते हैं, लेकिन वास्तव में आपके पास व्यापार विश्लेषकों या अंतिम उपयोगकर्ताओं से कोई संबंध नहीं है, तो आप कैसे सत्यापित कर सकते हैं कि आप उपयोगकर्ता कहानियों पर वितरित कर रहे हैं जब आपके पास वास्तव में यह जानने का कोई तरीका नहीं है कि यह उपयोगकर्ता क्या है चाहता हे?

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

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

यह उस तरह से काम करने वाला नहीं है

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

आप एक ऐसे वातावरण में काम नहीं करते हैं जो चुस्त परियोजना प्रबंधन के तरीकों के अनुकूल है। आप वाटरफॉल के तरीके के अनुकूल माहौल में भी काम नहीं करते हैं। आप एक राजशाही में काम करते हैं और आप केवल राजाओं के पंजे हैं जो उसकी बोली लगाते हैं और आग लगाते हैं।

यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट टीम का निर्माण नहीं है।

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


अफसोस की बात है कि मुझे डर है कि आपकी प्रतिक्रिया सही है .. हमें मूल रूप से हमारे सीआईओ के लिए कुछ भी स्थगित करने की आवश्यकता है, यहां तक ​​कि ऐसी चीजें जो उसे चिंता नहीं करती हैं कि हमें अपने एसवीएन को कैसे और कब शाखा देना चाहिए (हमें सिर्फ एक रोलबैक करना था, तीसरी बार में। एक पंक्ति, और हमारा CIO निर्णय ले रहा है कि हमें यह बताना चाहिए कि जब हमें कोई डेवलपर नहीं होना चाहिए, तो हमें शाखा कैसे लगानी चाहिए।
वेन मोलिना

1
@AyneM क्या सभी राजा घोड़ों और सभी राजाओं को एक साथ फिर से खाली डम्पी डाल सकते हैं, जब राजा एक सूक्ष्म प्रबंधन मूर्ख होता है? मेरा सामान्य अनुभव मुझे नहीं बताता है। यह वातावरण एक परियोजना में सॉफ्टवेयर लिखने के लिए अनुकूल नहीं है। यदि आप वास्तव में एक परियोजना टीम के लिए काम करने का अच्छा अनुभव चाहते हैं तो चारों ओर देखना शुरू करें क्योंकि आप इसे वहां नहीं ढूंढने जा रहे हैं।
maple_shaft

2
@WayneM इसके अलावा आपके CIO को अपनी प्राथमिकताएं सीधे प्राप्त करने की आवश्यकता है। यदि वह वास्तव में ग्राहक और उपयोगकर्ता की जरूरतों को पूरा करने के लिए आपकी उत्पाद लाइनों को निर्देशित करने पर ध्यान केंद्रित करने की कोशिश करता है, तो अपना बहुमूल्य समय बर्बाद करने के बजाय आपको बताएगा कि आप कैसे करते हैं, तो शायद कंपनी बहुत बेहतर काम करेगी। क्या सरासर बदहजमी।
maple_shaft

सबसे बुरी बात यह है कि वे गूंगे भाग्य के कारण मामूली रूप से सफल हैं, इसलिए वे समस्याएं भी नहीं देखते हैं।
वेन मोलिना

1
@WayneM डंब भाग्य या एक आला बाजार में राजनीतिक कनेक्शन? यह शायद बाद की बात है। व्यवसाय बहुत लंबे समय तक गूंगे भाग्य पर नहीं टिकते हैं। आपकी कंपनी को पीछे छोड़ने से अधिक कुशल प्रतियोगियों को रखने की संभावना केवल इस तरह के प्रवेश के लिए बाधाएं हैं।
maple_shaft

6

जैसा कि मैंने यहां उल्लेख किया है , यदि या तो स्क्रैम मास्टर या उत्पाद स्वामी के पास कार्य करने योग्य कार्य हैं, तो वे टीम के सदस्य भी हैं।

उस ने कहा, जब तक आप अपने CIO और अपने ग्राहकों दोनों से वास्तविक खरीद नहीं लेते हैं, तब तक आपको Agile की गंभीर समस्याएं होने वाली हैं। क्या आपका सीआईओ इस तथ्य का पालन करने के लिए तैयार है कि वह एक कार्य मद मध्य-स्प्रिंट को जोड़ नहीं सकता है, लेकिन अगले तक इंतजार करना होगा? क्या वह विकसित की जाने वाली वस्तुओं को प्राथमिकता देने के लिए तैयार है? आपने जो लिखा है, उससे ऐसा लगता है कि वह जो करता है, उसका मालिक है, और इस प्रकार वह उत्पाद स्वामी होना चाहिए। यदि वह अनिच्छुक है, तो आप वर्तमान में आपके द्वारा किए गए कार्यों से अधिक सफल नहीं होंगे।


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

1

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


1

Scrum कुछ पर विचार करने के लिए, निश्चित है। हालाँकि, एक ही पृष्ठ पर सभी को शामिल करने और इस पद्धति का उपयोग करने में विभिन्न प्रारंभिक मुद्दों को हल करने के लिए कम से कम कुछ स्प्रिंट प्राप्त करने के साथ संरचना में कुछ बदलावों को स्वीकार करने के लिए कुछ कहा जाना है।

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

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