2011-01-11 16 views
11

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

परिणाम अच्छे लगते हैं, और मुझे उत्पादन कार्यान्वयन परियोजना की योजना बनाने के लिए आगे बढ़ने दिया गया है।

मैंने पहले इस तरह का काम किया है, इसलिए मुझे पता है कि सॉफ्टवेयर के कार्यात्मक घटक कैसे हैं। मुझे डेटा लाने के लिए वेब क्रॉलर के संग्रह की आवश्यकता है। मुझे क्रॉल किए गए दस्तावेज़ों से विशेषताओं को निकालने की आवश्यकता है। उन दस्तावेजों को "प्रशिक्षण सेट" और "वर्गीकरण सेट" में अलग करने की आवश्यकता है, और प्रत्येक दस्तावेज़ से फीचर-वेक्टर निकालने की आवश्यकता है। वे फीचर वैक्टर क्लस्टर में स्वयं संगठित होते हैं, और क्लस्टर को रीबैलेंसिंग ऑपरेशंस की एक श्रृंखला के माध्यम से पारित किया जाता है। आदि आदि आदि

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

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

तो मैं परियोजना के शीर्ष स्तर पर कोई उपयोगकर्ता कहानी बनाई:

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

या हो सकता है एक बेहतर इस सुविधा के लिए उच्च-स्तरीय कहानी होगा:

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

लेकिन यह वास्तविक समस्या नहीं है।

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

बिंदु में मामला ... मुझे पता है कि एल्गोरिदम के लिए दो प्रमुख वास्तुशिल्प उपखंडों की आवश्यकता होती है: (ए) प्रशिक्षण, और (बी) वर्गीकरण। और मुझे पता है कि वास्तुकला के प्रशिक्षण हिस्से को क्लस्टर-स्पेस के निर्माण की आवश्यकता है।

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

लेकिन क्लस्टर-स्पेस, और अपने आप में, शून्य व्यापार मूल्य प्रदान करता है।न ही क्रॉलर, या फीचर-एक्सट्रैक्टर। आंशिक प्रणाली में कोई व्यावसायिक मूल्य नहीं है (अंतिम उपयोगकर्ता के लिए नहीं, या कंपनी के लिए आंतरिक भूमिकाओं में से किसी के लिए)। एक प्रशिक्षित क्लस्टर-स्पेस केवल क्रॉलर और फीचर एक्स्ट्रेक्टर के साथ ही संभव है, और केवल प्रासंगिक है यदि हम एक साथ क्लासिफायरफायर भी विकसित करते हैं।

मुझे लगता है यह उपयोगकर्ता कहानियों बनाने के लिए संभव हो जाएगा जहां कहानियों में उपयोगकर्ताओं के रूप में प्रणाली अधिनियम के अधीनस्थ घटकों:

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

लेकिन यह वास्तव में अजीब लगता है। यह मुझे अपने उपयोगकर्ता की कहानियों को मॉडल करने के लिए डेवलपर (या हमारे उपयोगकर्ताओं, या किसी अन्य हितधारकों, उस मामले के लिए) के रूप में मुझे क्या लाभ प्रदान करता है?

हालांकि मुख्य कहानी को आर्किटेक्चरल-घटक सीमाओं (क्रॉलर, ट्रेनर, वर्गीकृत, आदि) के साथ आसानी से विभाजित किया जा सकता है, मैं किसी उपयोगकर्ता के परिप्रेक्ष्य से किसी भी उपयोगी अपघटन के बारे में नहीं सोच सकता।

आप क्या सोचते हैं? परिष्कृत, अविभाज्य, गैर-उपयोगकर्ता-सामना करने वाले घटकों के लिए आप Agile उपयोगकर्ता कहानियों की योजना कैसे बनाते हैं?

उत्तर

0

किसी भी कहानी में एक भूमिका, एक क्रिया, और एक लक्ष्य है। तो, एक कहानी लिखने के बारे में सोचें जो एक भूमिका (ए/के/एक अभिनेता) को लक्ष्य प्राप्त करने के लिए कुछ कर रही है।

जो आपने डाला है, उसके पास एक स्पष्ट परीक्षण होना चाहिए, यानी, एक प्रभावी निर्णय प्रक्रिया जो सफलता और विफलता को परिभाषित करती है।

जहां आप परेशानियों में भाग रहे हैं, मुझे लगता है, "व्यापार मूल्य" में पकड़ा जा रहा है। कुल मिलाकर परिभाषित करके शुरू करें कि आप अपना कार्य सफलतापूर्वक पूरा करते समय कैसे जानेंगे। फिर, "चाकू व्यापार मूल्य" लक्ष्य की ओर कुछ प्रगति कर रहा है।

आपको एग्इल में कुछ चीजों के साथ एक छोटा सा रचनात्मक होना है, क्योंकि वे अक्सर व्यावसायिक प्रक्रियाओं के प्रति उन्मुख होते हैं।

अद्यतन:

यहां कई बिंदुएं हैं।

  1. यह एक प्रमेय है कि यदि आप प्रणाली के बाहर से एक घटक के किसी भी प्रभाव का पालन नहीं कर सकते हैं, तो उस घटक अवलोकन तुल्यता के अर्थ में प्रभाव के बिना हटाया जा सकता है।

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

    1. बड़ा कहानियों सेट करें और उन्हें substeps का एक असामान्य रूप से बड़ी संख्या

    2. में तोड़ कहानियों घुलना:

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

+0

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

1

'लंबवत स्लाइस' अवधारणा का उपयोग करना उपयोगी हो सकता है। एक साधारण 3-परत अनुप्रयोग की कल्पना करें (उदाहरण के लिए यूआई/तर्क/डीबी)। एक परत बनाने के बजाय, फिर दूसरा, आप तीनों के माध्यम से लंबवत 'टुकड़ा' करते हैं। एक प्रारंभिक कहानी "उपयोगकर्ता के रूप में, मैं सिस्टम में लॉग इन करने में सक्षम होना चाहता हूं, ताकि मैं इसे एक्सेस कर सकूं।" जब पूरा हो जाए, तो यह कहानी संभावित रूप से शिप करने योग्य है, जिसमें यह पूर्ण कार्यक्षमता प्रदान करता है, लेकिन वास्तव में शिपिंग के लायक बनाने के लिए ग्राहक को पर्याप्त मूल्य प्रदान करने की संभावना नहीं है। ऊर्ध्वाधर स्लाइस का एक लाभ यह है कि आपने सभी परतों, ज्ञान के बारे में कुछ सीखा है जो भविष्य के पुनरावृत्तियों में उपयोग किया जा सकता है।

आप इसके साथ परिचित नहीं हैं तो, निवेश मॉडल उपयोगकर्ता की कहानियाँ लिए बहुत उपयोगी है:

मैं - स्वतंत्र

एन - बातचीत योग्य

वी - मूल्यवान

ई - अनुमानित

एस - आकार का उचित

टी - टेस्टेबल

+0

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

+0

इस पर टीम कितनी बड़ी काम कर रही है? आप यात्रा की 'चिकनीपन' के बारे में कितने निश्चित हैं? प्रोजेक्ट mgrs और mgmt बनाने के अलावा इसे 'असली' उपयोगकर्ता कहानियों में डालने में कोई मूल्य है। खुश? आपकी दौड़ कितनी देर तक हैं? –

0

मुझे लगता है कि आप आंशिक प्रणाली के लिए सही या गलत परिणाम भी माप सकते हैं। आपको अन्य सिस्टम घटकों को बाहर निकालना होगा। यह निश्चित रूप से संभवतः है। इसके अलावा, मेरी राय में यह समझ में आता है कि सिस्टम का एक हिस्सा अन्य मॉड्यूल के लिए एक अभिनेता है।

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