UX डिजाइनर एक स्प्रिंट के आगे काम कर रहे हैं

Question

हमारे यूएक्स डिजाइनरों की आमतौर पर स्प्रिंट एक्स में एक कहानी होती है जो डेवलपर्स स्प्रिंट एक्स + 1 में लागू करेंगे (यूएक्स डिजाइनर और देव / परीक्षक एक टीम पर हैं)। मुझे लगता है कि यह समझ में आता है क्योंकि अगर आपके पास स्क्रीन मॉकअप और स्पष्ट विनिर्देश नहीं हैं तो आप स्प्रिंट प्लानिंग के दौरान काम का अनुमान नहीं लगा सकते।

हालाँकि, Scrum में आपको केवल उपयोगकर्ता कहानियां ही मिलनी चाहिए जो उपयोगकर्ता को मूल्य प्रदान करती हैं। हमारे मामले में यूएक्स डिजाइन की कहानियां ऐसा मूल्य प्रदान नहीं करती हैं (वे एक बैकलॉग ग्रूमिंग गतिविधि की तरह अधिक हैं)। आमतौर पर स्क्रम कोच स्प्रिंट की शुरुआत से पहले पूर्ण विनिर्देशों की सिफारिश नहीं करते हैं, एक सिफारिश जिसे मुझे समझना मुश्किल है।

तो क्या आप हमारे दृष्टिकोण में कोई कमी देखते हैं? यह हमारे लिए काम करने लगता है, लेकिन यह कुछ हद तक स्क्रैम सिद्धांतों के खिलाफ है।

Comments

यूएक्स डिजाइन उपयोगकर्ता को मूल्य क्यों नहीं प्रदान करेगा? यह मानते हुए कि आप UX डिजाइनरों का उपयोग करना चाहते हैं और जारी रखते हैं, मैं नहीं देख सकता कि कोई विकल्प है, और यदि आपके पास कोई विकल्प नहीं है, तो नुकसान कैसे हो सकता है?

— माइकल शॉ

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

— यूजीन

आपकी समस्या यह हो सकती है कि आपके पास डिजाइनर या आदर्श रूप से UX इंजीनियर नहीं हैं, आपके पास ग्राफिक कलाकार हैं। वे सिर्फ फ़ोटोशॉप का उपयोग करते हैं, है ना? कोई CSS JS या XAML या इंटरफ़ेस बिल्डर या कोई फ्रंट-एंड तकनीकी चॉप नहीं है? इसलिए आपके पास डिजाइनर नहीं हैं। आपको असली डिज़ाइनर चाहिए। तब आपको यह भ्रम नहीं होगा।

— रिबेल्डैडाई

नहीं। हमारे पास उपयोगकर्ता इंटरैक्शन डिजाइनर और ग्राफिक डिजाइनर दोनों हैं। दोनों विकास के आगे एक काम करते हैं

— यूजीन

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

— BobDalgleish

Answer 1

हालाँकि, Scrum में आपको केवल उपयोगकर्ता कहानियां ही मिलनी चाहिए जो उपयोगकर्ता को मूल्य प्रदान करती हैं।

मूल्य केवल shippable कोड की लाइनों में नहीं मापा जाता है।

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

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

Comments

"वर्किंग सॉफ्टवेयर प्रगति का प्राथमिक माप है।", UX नहीं। UX कुछ भी नहीं लायक है अगर यह सॉफ्टवेयर काम नहीं कर रहा है। यदि आपके पास एक ही समय में UX होने की वकालत की जाती है या वास्तविक सुविधा को बाद में w / r / t करने की वकालत की जाती है , लेकिन आप ऐसा नहीं करते हैं, तो यह उत्तर बिल्कुल गलत है।

— स्किलिविज़

@ संजीव: मुझे लगता है कि हमें असहमत होने के लिए सहमत होना होगा। हालांकि यह सच है कि काम करने वाला सॉफ्टवेयर प्रगति का प्राथमिक उपाय है, यह एकमात्र उपाय नहीं है। किसी टीम को कोडिंग शुरू करने से पहले डिजाइन की कुछ मात्रा को सामने रखना होगा। UX ऐसा कुछ नहीं है, जिस पर आप अंत में निपट सकते हैं।

— ब्रायन ओकले

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

— डेरेक डेविडसन पीएसटी सीएसटी

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

— यूजीन

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

— जूल्स

Answer 2

मुख्य नुकसान ये हैं:

1. आप पाइप-लाइनिंग कर रहे हैं: यदि आपके डिजाइनर देर से हैं, तो आपके डेवलपर्स काम के बिना छोड़ दिए जाते हैं; यदि आपके डेवलपर्स देर से हैं, तो आपका डिजाइनर अंततः अग्रिम में एक से अधिक पुनरावृत्ति का काम करेगा। यह एक स्थिर स्थिति नहीं है - यह टिकाऊ नहीं है ।

2. आपके डिजाइनर पहले से काम कर रहे हैं, आप उन कहानियों के लिए लागत का भुगतान कर रहे हैं जो विकसित हो सकती हैं या नहीं। अगर ऐसा कम ही होता है, तब भी आप पैसे फेंक रहे हैं।

3. आपके UX डिजाइनर डेवलपर्स को शामिल किए बिना अग्रिम में निर्णय ले रहे हैं। आप उपयोगी अंतर्दृष्टि को याद कर रहे हैं और जोखिम बढ़ा रहे हैं कि डिजाइन फ्लैट गलत या अवास्तविक हैं। यह काफी सामान्य है क्योंकि UX डिजाइन एक "अमूर्त" व्यायाम नहीं है - इसे एप्लिकेशन की विशेषताओं से बाहर तैयार किया जाना चाहिए (तकनीकी रूप से ऐसा करने या न करने के लिए क्या संभव है / उचित है)

4. अपने डेवलपर्स को छोड़कर या डिसमोवरिंग करना प्रोजेक्ट चलाने का एक स्थायी तरीका नहीं है।

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

6. आप यह मान रहे हैं कि एक कहानी जो डिजाइनरों के लिए एक पुनरावृत्ति में फिट हो सकती है, डेवलपर्स के लिए एक पुनरावृत्ति में फिट होती है: आप कहानियों को कैसे विभाजित कर सकते हैं ताकि यह धारणा सही हो?

Comments

टिप्पणियाँ काफी हद तक विषय से दूर थीं इसलिए हटा दी गई हैं।

— ChrisF

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

— ब्रायन ओकली

@ या तो वे ux पर काम करते हैं या वे नहीं करते हैं। निश्चित रूप से ऑक्स प्रक्रिया में शामिल होना एक कहानी पर "काम" के रूप में योग्य है। मूल्य के आपके मूल्यांकन के बारे में ... वे अग्रिम में काम करने पर मूल्य नहीं जोड़ते हैं क्योंकि वे कुछ भी उत्पन्न नहीं करते हैं जो तैनात किया जा सकता है। अगर कुछ कभी ग्राहक तक नहीं पहुंचता है तो इसका कोई मूल्य नहीं है।

— स्किलिविज़

पुन: "ओक्स प्रक्रिया में शामिल होना एक कहानी पर" काम करने "के रूप में योग्य है।" जरुरी नहीं। लोग आते हैं और मुझसे हर समय सवाल पूछते हैं, इसका मतलब यह नहीं है कि मैं उनकी कहानियों पर काम कर रहा हूं।

— ब्रायन ओकले

@BryanOakley निश्चित रूप से, लेकिन समस्याएं अभी भी लागू होती हैं: एक डिजाइन को "वापस भेजने" की तुलना करें क्योंकि यह निष्पादित करने के लिए अवास्तविक है बनाम इसे पहली बार सही करना क्योंकि यह तब हुआ है जब एक डेवलपर इस पर काम कर रहा है। इसके अलावा, ऐसे मुद्दे हैं जो केवल कार्यान्वयन के दौरान खोजे गए हैं, और उस स्तर पर डिजाइनर अगली कहानी कर रहा है ...

— स्लीपविज़

Answer 3

मुझे यह पसंद है, दो कारणों से:

1. यह आपके लिए काम करने लगता है; सफलता के साथ बहस करना कठिन है!
2. UX टीम कहानी लेती है और बातचीत को जल्दी शुरू करती है - और बातचीत कहानियों के प्रकार की तरह हैं

Answer 4

Scrum की एक बुनियादी आवश्यकता यह है कि scrum टीम के पास संभावित releasable उत्पाद बनाने के लिए आवश्यक सभी कौशल हैं। जिस स्थिति का आप वर्णन करते हैं, ऐसा नहीं हो रहा है।

यूएक्स टीम संभावित रूप से भरोसेमंद उत्पाद का उत्पादन नहीं कर रही है और स्क्रैम टीम कार्यक्षमता के ऊर्ध्वाधर स्लाइस का उत्पादन करने में सक्षम नहीं है क्योंकि उनके पास सभी आवश्यक कौशल नहीं हैं। ये दुष्क्रिया हैं।

स्किलिविज़ ने उन समस्याओं पर एक उत्कृष्ट पोस्ट लिखी है जो उपरोक्त बीमारियों का कारण बन सकती हैं। सारांश में, मुझे नहीं लगता कि आप स्क्रैम का अभ्यास कर रहे हैं।

लेकिन इसमें कुछ भी गलत नहीं है। यदि आपने काम करने का एक तरीका खोज लिया है जो आप सभी के लिए मूल्य प्रदान करता है, और आप सभी इससे खुश हैं, तो इसे करते रहें। मेरी एकमात्र सलाह बार-बार निरीक्षण और अनुकूलन करना होगी।

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

Comments

जैसा कि मैंने अपने मूल पोस्ट में कहा था: "UX डिजाइनर और देव / परीक्षक एक टीम में हैं"

— यूजीन

@ यूजीन किस अर्थ में वे एक ही टीम में हैं? मैं कहूंगा कि अगर वे एक स्प्रिंट से आगे काम कर रहे हैं, तो वे एक ही टीम में नहीं हैं। संयोग से, स्क्रम भी स्पष्ट है कि यह "उप-टीमों" को इतनी बार नहीं पहचानता है, मैं कहूंगा कि आपकी स्थिति स्क्रम की तरह नहीं है। निश्चित रूप से नहीं जैसा कि मुझे पता है।

— डेरेक डेविडसन पीएसटी सीएसटी

वे बाकी समय के साथ एक स्प्रिंट आगे काम करते हैं। टीम के बाकी सदस्य आमतौर पर कम से कम अपने काम की समीक्षा करते हैं और कभी-कभी डिजाइन के साथ ही मदद करते हैं।

— यूजीन

Answer 5

यहाँ दो मुद्दे हैं, एक उपयोगकर्ता केंद्रित डिज़ाइन के बारे में और दूसरा स्प्रिंट अलाइनमेंट के बारे में।

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

"उपयोगकर्ताओं को कई पृष्ठों के बीच विभाजित होने के बजाय एक पृष्ठ पर खाता गतिविधि के लिए आसान पहुंच होगी"

विभिन्न कार्यान्वयनों के लिए उत्तरदायी और अनुकूलनीय है और फिर भी उपयोगकर्ता के मूल्य (खाता गतिविधि तक आसान पहुंच) के बारे में स्पष्ट है।

दूसरा : स्प्रिंट संरेखण। UX स्प्रिंट एक्स में विशेषताएं डिजाइन करता है जो डेवलपर्स स्प्रिंग एक्स + 1 में लागू करते हैं। व्यवहार में, यह कई दुकानों में होता है और कभी-कभी यह स्प्रिंट एक्स + 2 या एक्स + 3 में कार्यान्वयन की तरह हो सकता है। एक तंग नाइट और अनुभवी टीम के साथ यह सेटअप काम कर सकता है। यदि आपके पास एक नई टीम या नए सदस्य हैं जो टीम के अन्य सदस्यों के कौशल सेट, वरीयताओं, आदतों, कार्यशैली, और प्रवृत्तियों से परिचित नहीं हैं तो यह चुनौतीपूर्ण हो जाता है। यदि आप 6 महीने से कम समय से एक साथ काम कर रहे हैं तो यह एक मुद्दा होने की संभावना है।

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

Answer 6

संभावित समस्याओं में से एक मैं देख रहा हूं कि स्क्रम में स्प्रिंट एन + 1 के लिए गुंजाइश सामान्य रूप से शुरू होने से ठीक पहले निर्धारित की जाती है। तो आप स्प्रिंट एन में स्प्रिंट एन + 1 कहानियों के लिए यूएक्स कैसे कर सकते हैं इससे पहले कि आप जानते हैं कि कौन सी कहानियां दायरे में होंगी। यदि आप स्प्रिंट एन + 1 के स्प्रिंट एन के लिए गुंजाइश को ठीक करने का निर्णय लेते हैं तो आप कुछ लचीलापन खो देते हैं।

Answer 7

हालाँकि, Scrum में आपको केवल उपयोगकर्ता कहानियां ही मिलनी चाहिए जो उपयोगकर्ता को मूल्य प्रदान करती हैं। हमारे मामले में यूएक्स डिजाइन की कहानियां ऐसा मूल्य प्रदान नहीं करती हैं (वे एक बैकलॉग ग्रूमिंग गतिविधि की तरह अधिक हैं)।

जिस तरह से मैं इसे देखता हूं, वे अपने उपयोगकर्ता को बहुत सारे मूल्य प्रदान कर रहे हैं। बात यह है: उनका उपयोगकर्ता कंपनी का अंतिम उपयोगकर्ता नहीं है, उनका उपयोगकर्ता विकास टीम है जो स्प्रिंट एक्स + 1 पर सुविधा को लागू करेगा।

Answer 8

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

मुझे लगता है कि आपके समूह ने गुमराह किया है कि आपके उपयोगकर्ता कौन हैं और गलत दर्शकों के लिए योजना बना रहे हैं।

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

यही कारण है कि यह आपके लिए गलत लगता है, आपको वास्तव में किसी भी तरह से घोटाले की आवश्यकता या लाभ नहीं है क्योंकि आप एक सेवा समूह में हैं और आपका काम यूएक्स लोगों से आगे बढ़ता है जो पहले से ही चुस्त / स्क्रम भागों का काम कर चुके हैं।

वहाँ वास्तव में कुछ भी बुरा नहीं है, बस एक अलग प्रक्रिया आपके द्वारा बताई गई जगह की तुलना में है।