2009-11-26 11 views
10

के साथ इकट्ठा करने की आवश्यकताएं मेरी विकास टीम स्क्रम पद्धति के लिए काम कर रही है, काफी ज्यादा। हमारे पास प्राथमिकता वाले उत्पाद बैकलॉग हैं, जिसे हम एक विस्फोट चार्ट द्वारा ट्रैक किए गए स्पिंट में विभाजित करते हैं।स्क्रम

समस्या यह है कि उत्पाद प्रबंधकों (जो हितधारकों से आवश्यकताओं को इकट्ठा करते हैं) हमें स्प्रिंट की शुरुआत से पहले या स्पिंट्स के सेट से कुछ दिन पहले आवश्यकताओं की रूपरेखा देंगे।

फिर हम उनके माध्यम से एक नज़र डालें, उन्हें व्यवहार्य (तकनीकी रूप से और उचित समय के भीतर) के साथ संशोधित करें। यह प्रबंधन, अन्य उत्पाद प्रबंधन और हितधारकों द्वारा समीक्षा के लिए भेजा जाता है, और आमतौर पर संशोधित/tweaked आगे, जो एक सर्कल में जाने के लिए जाता है जब तक कि यह सब ठीक हो गया है।

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

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

क्या किसी के पास इस तरह के किसी भी मुद्दे का कोई सुधार सुझाव या अनुभव है?

संपादित करें: यह शायद हमारे लिए सबसे खराब स्थिति परिदृश्य है - कभी-कभी आवश्यकताएं बहुत स्थिर होती हैं और हम वास्तव में स्क्रम का सही ढंग से उपयोग करते हैं! हालांकि, हम अक्सर हमारे sprints में उपरोक्त परिदृश्य देख रहे हैं, यही कारण है कि मैंने सवाल पूछा है। मुझे पता है कि उपर्युक्त वास्तव में उचित स्क्रम नहीं है, यह समस्या का प्रकार है :)

+4

मैं इस प्रश्न को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह प्रोग्रामिंग के बारे में नहीं है। –

उत्तर

6

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

बदलती आवश्यकताओं पर; Agile घोषणापत्र देखें ... "परिवर्तन गले लगाओ!"

दया,

दान

+0

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

+2

स्टोकहोल्डर्स "मुर्गियां" होना चाहिए, न कि "सूअर" (जैसे "उनकी खाल खेल में नहीं हैं")। वे सुन सकते हैं लेकिन बात नहीं करनी चाहिए। प्रबंधन समीक्षा पर टिप्पणी के लिए –

14

हां। और यह महत्वपूर्ण है: स्प्रिंट शुरू होने के बाद कहानियों में परिवर्तन स्वीकार न करें।

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

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

यदि आपके उत्पाद के मालिक को पता चलता है कि यह बहुत लचीला है, तो वसंत की लंबाई को कम करने पर विचार करें। मैंने एक दुकान में काम किया है जो एक हफ्ते का एक स्प्रिंट इस्तेमाल करता है, जिसे मैं न्यूनतम मानता हूं, क्योंकि कहानियां बहुत छोटी होती हैं।

अधिक जानकारी के लिए Agile Project Management केन श्वाबर द्वारा स्क्रम के साथ देखें।

2

हमारे पास उस टीम में कोई है जो उत्पाद स्वामी की तरफ से आवश्यकताओं को ठीक करने का प्रभारी है। कभी-कभी हमारे पास समय-समय पर आवश्यकताएं होती हैं, कभी-कभी, हमारे पास कुछ काम करने की ज़रूरत होती है। क्यूए स्वीकार करता है कि रिलीज के नवीनतम दौड़ में औपचारिक रूप से आवश्यकताओं की समीक्षा की जाती है।

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

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

2

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

5

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

कृपया उस एग्इल विधि या स्क्रम को कॉल न करें।

यह सिर्फ पागलपन है।

यदि आप स्प्रिंट शुरू होने के बाद चीजें बदल रहे हैं, तो आप इसे सही नहीं कर रहे हैं।

आप (वास्तव में, आपके उत्साहजनक) बुरे व्यवहार को सक्षम कर रहे हैं। अगर वे से पहले आवश्यकताओं को प्राप्त नहीं कर पा रहे हैं, तो आपके पास दो विकल्प हैं।

  1. रुको। इसके साथ कुछ भी गलत नहीं है। यह लंबे समय तक सस्ता है।

  2. प्रारंभ करें। तथापि। चूंकि स्प्रिंट की अवधि के लिए आवश्यकताओं को ठीक किया गया है, इसलिए आपको स्प्रिंट को "ट्वीविंग" के साथ खत्म करना होगा। परिवर्तन बैकलॉग का हिस्सा बन जाते हैं।

    • आप छोटे स्पिंट्स कर सकते हैं।

    • आप तब तक ट्विकॉग बैकलॉग कर सकते हैं जब तक कि उन्हें यह विचार न हो कि वे अपनी समस्याएं पैदा कर रहे हैं।

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

+0

+1 - बिल्कुल सही, आईएमओ –

1

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

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

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

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

संबंधित मुद्दे