2008-09-23 23 views
7

हम अपने वर्तमान काम पर चुस्त विकास करने का प्रयास करते हैं और हम अधिकांश भाग के लिए सफल होते हैं। मुख्य समस्या यह प्रतीत होती है कि प्रोजेक्ट के डेवलपर्स हमेशा स्प्रिंट की शुरुआत में आवश्यकताओं की प्रतीक्षा कर रहे हैं और अंत तक चीजों को पाने के लिए दौड़ रहे हैं। व्यावसायिक विश्लेषकों जो आवश्यकताओं को पूरा कर रहे हैं हमेशा आवश्यकताओं को पूरा करने के लिए गैर-स्टॉप काम कर रहे हैं।एससीआरयूएम जैसे पुनरावृत्त फुर्तीली विकास विधियों का उपयोग करते समय आप आवश्यकताओं की प्रतीक्षा करने से कैसे बचते हैं?

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

संपादित करें: अधिक अंतर्दृष्टि/भ्रम शायद: मुझे आश्चर्य है अगर समस्या का हिस्सा है कि स्क्रीन कि अनुकूलित किया जा रहा है पहले से ही वहाँ के रूप में यह एक तख्त उत्पाद है कि भारी अनुकूलित किया जा रहा है कर रहे हैं। लोग सुझाव देते हैं कि उपयोगकर्ता कहानियां 'एक्स बनाने वाली स्क्रीन बनाने' के आधार पर होनी चाहिए। यह पहले ही हो चुका है। हो सकता है कि इन आवश्यकताओं के लिए उपयोगकर्ता कहानियां करने का कोई अच्छा तरीका न हो ... शायद इसे एक नया प्रश्न होना चाहिए।

उत्तर

9

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

3

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

अद्यतन अद्यतन

यह मुझे उन लोगों के लिए लगता है वास्तव में तो कहानियों के रूप में अपने दम पर खड़े नहीं है और हो सकता है बीए टीम पुनर्मूल्यांकन के लिए कैसे वे कहानियाँ लिख रहे हैं की जरूरत है। मेरा मतलब है कि आप कस्टमाइज़ एक्स स्क्रीन के साथ "एक कहानी बताएं" को फिर से नहीं चला सकते हैं। सिद्धांत रूप में एक कहानी की तरह "उपयोगकर्ता स्क्रीन एक्स को जाता है जब वे (बचाने के लिए और) को संशोधित करने में सक्षम होना चाहिए floozit"

+0

हम्म ... समस्या यह है कि स्क्रीन पहले से ही है ... इसलिए परिवर्तन 'इस क्षेत्र को यहां पर ले जाएं' या 'इस क्षेत्र को XXXXXXX की तरह गणना करने की आवश्यकता है, इसके बजाय यह अब कैसे है' । हमारी आवश्यकताओं के दस्तावेज़ जो हमें प्राप्त होते हैं वे मूल रूप से स्क्रीन के लिए बदलने के लिए इनमें से एक बड़ी सूची हैं। –

+0

दिलचस्प। मेरा पहला विचार तब होगा क्यों उन वस्तुओं में से प्रत्येक को अल्बियेट बहुत कम जटिलता कहानियां नहीं बनाते हैं। यदि यह व्यवहार्य नहीं है या बस समय बर्बाद है तो मैं अन्य लोगों ने जो कहा है उसके साथ जाऊंगा और बीएएस से उन सूचियों को प्रक्रिया में पहले प्राप्त करने के लिए कहूंगा। – JoshReedSchramm

+0

यह समस्या है। इस आवश्यकता दस्तावेजों को एक साथ रखकर बीएएस का एक बड़ा बैकलॉग है। यह हर स्प्रिंट समीक्षा सत्र में लाया जाता है। हम उन्हें जल्द से जल्द करने के लिए कहते हैं, लेकिन वे नॉनस्टॉप काम कर रहे हैं। –

2

BAs की तरह लगता है कुछ किया जाना चाहिए एक में स्प्रिंट के लिए आप अपने उपयोगकर्ता कहानियों सौंपने नहीं किया जा सकता समय पर ढ़ंग से।

मुझे लगता है कि आप जो कहते हैं उससे कोई स्प्रिंट योजना सत्र नहीं है।

यह देखते हुए कि स्क्रम के बड़े सिद्धांतों में से एक यह है कि विकास दल प्रति स्प्रिंट पर काम करने के लिए जिम्मेदारी लेता है, ऐसा लगता है कि यह मेरे लिए बहुत चुस्त नहीं है! (-:

छोटे स्पिंट होने के अलावा।

+0

हमारे व्यापार मालिक और स्क्रम मास्टर उन चीजों की सूची के साथ आते हैं जो हम स्प्रिंट के लिए करते हैं और फिर उन्हें निर्दिष्ट करते हैं। हमारे नियोजन सत्र में हम आम तौर पर केवल अनुमान प्रदान करते हैं, इसलिए वे बहुत उपयोगी नहीं हैं। हम स्प्रिंट प्लानिंग में भी कार्यों के लिए स्वयंसेवक थे ... अब –

4

यदि मैं आपकी स्थिति को सही ढंग से समझता हूं, तो बीए पीछे गिर रहे हैं। दो चीजें हैं जो आप कोशिश कर सकते हैं।

  1. या तो छोटे स्पिंट या छोटी आवश्यकता भाग का प्रयास करें। किसी भी तरह से बीएएस के लिए काम अधिक संक्षिप्त और प्रबंधनीय होना चाहिए।

  2. पुनर्विक्रय या बग स्क्वैश के लिए एक इंटरैक्शन लें। यह वक्र से आगे निकलने के लिए बीएएस को कभी-कभी देना चाहिए।

अगर, हालांकि, समस्या यह है कि BAs अधिक आवश्यकताओं आप बहुत बड़ा मुद्दे हैं करने से पहले "जंगली" में पिछले आवश्यकताओं देखने की जरूरत है। :)

+0

से मुझे आश्चर्य नहीं है कि क्या हमारे उपयोगकर्ता कहानियों में कोई समस्या है कि वे बहुत अस्पष्ट हैं/समय से पहले सेट हैं। –

1

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

आशा इस मदद करता है

1

"उपयोगकर्ता कहानी" एक भविष्य बातचीत के लिए एक प्लेसहोल्डर है, तो ग्राहकों के सामने लाने के लिए और उन्हें पूछना; अगर वह बीए का काम है, तो आग लगाना ;-)

1

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

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

0

मैं इस संभाल करने के लिए कुछ तरीके देखें:

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

दैनिक जमघट के दौरान

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

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

0

आसान।

की अनुमति दें खुद स्क्रम के कड़े नियमों के बाहर लगता है, और अपने दुबला जड़ों को वापस पाने के लिए: http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

ट्रस्ट मुझे, एक बार आपको लगता है कि प्रवाह के लिए जा रहा है, तो आप वापस देखो कभी नहीं होगा।

0

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