स्क्रम: क्या उपयोगकर्ता कहानी के डिजाइन / UX को कार्यान्वयन के समान स्प्रिंट में होना ठीक है


9

मैं वर्तमान में स्प्रिंट (दो सप्ताह) में हूं जहां डिजाइनर को एक विशेष उपयोगकर्ता कहानी की आवश्यकताओं और यूएक्स को परिभाषित करने का काम सौंपा गया है।

उसी स्प्रिंट में, मैं इस डिजाइन को लागू करने के लिए हूं। स्प्रिंट प्लानिंग के दौरान, मुझे यह अनुमान लगाना पड़ा कि इस अपरिभाषित उपयोगकर्ता की कहानी में कितना समय लगेगा।

आज मुझे आखिरकार डिजाइन प्राप्त हुआ। दुर्भाग्य से, डिजाइन अधूरा / अस्पष्ट है और डिजाइन की तुलना में ग्राहक की आवश्यकताओं के लिए अधिक महत्वपूर्ण है। हालाँकि, इससे मैं अभी भी देख सकता हूँ कि मैंने लगभग पर्याप्त अनुमान नहीं लगाया है।

मामलों को बदतर बनाने के लिए यह पहली बार नहीं है। पिछले स्प्रिंट में, ठीक वही बात हुई। मैंने इसे हमारे पूर्वव्यापी में झंडी दिखा दी और स्क्रैम मास्टर के पास इस बात का जवाब नहीं था कि इसे कैसे हल किया जाए, बजाय इसके कि "यह सिर्फ आपके लिए विकास है"। विडंबना यह है कि अगर गुस्सा निशाने पर न हो तो वह नाराज हो जाता है ...

अब मुझे अपना काम पूरा करने के लिए डिजाइनर से पूछना / काम करना होगा। यह मुझे पकड़ कर रखने वाला है क्योंकि मैंने अपने अन्य सभी कार्य पूरे कर लिए हैं।

तो मेरा सवाल है

  • ए) आप स्प्रिंट योजना में निर्भरता कैसे संभालते हैं? EDIT: कार्यान्वयन के रूप में एक ही स्प्रिंट में होने के लिए उपयोगकर्ता कहानी के डिजाइन / UX के लिए ठीक है
  • ख) अब मुझे स्प्रिंट से कैसे संपर्क करना चाहिए? वर्तमान उपयोगकर्ता कहानी का पुनर्मूल्यांकन करें और बर्नडाउन को बर्न में देखें और अक्षम / अनुत्पादक के रूप में देखें? या "एक उपयुक्त डिजाइन बनाने में डिजाइनर की मदद" की तर्ज पर वर्तमान स्प्रिंट में एक नया कार्य जोड़ें


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

    जवाबों:


    14

    आप स्प्रिंट योजना में निर्भरता कैसे संभालते हैं?

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

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

    यह जो करता है वह अनुमान लगाने की अपेक्षाकृत ठोस डिजाइन के बिना अनुमान की अनिश्चितता को दर्शाता है। शायद, यह आपके प्रबंधकों को यह सुनिश्चित करने के लिए प्रोत्साहित करेगा कि उत्पाद बैकलॉग आइटम ठीक से परिभाषित है; लेकिन सबसे बुरी तरह से यह आपकी पीठ को कवर करेगा। अंडर-बजट में नौकरी आने पर कोई शिकायत नहीं करता।

    हालाँकि, आपने ऐसा नहीं किया, और अब आपका प्रश्न यह है ...

    अब मुझे स्प्रिंट से कैसे संपर्क करना चाहिए?

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

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


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

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

    1
    @ ऑलन: आपका स्कैम मास्टर क्या समझने में असफल है, अगर डिजाइनर को किसी डेवलपर के काम शुरू करने से पहले अपना काम पूरा करना होता है, तो वह है आईएस अप-फ्रंट डिज़ाइन। स्प्रिंट के भीतर ऐसा करने से अप-फ्रंट डिज़ाइन की कोई भी लागत नहीं निकलती है, लेकिन यह इसे कम-दिखाई देता है और आपके विकास का अनुमान लगाने में कठिन बनाता है। यदि आप अपने डिजाइनर के साथ पुनरावृति करने का एक तरीका खोज सकते हैं, तो यह बहुत अच्छा है, इसे स्प्रिंट का हिस्सा बनाएं और प्रयास को एक सहयोगी कार्य के लिए उपयुक्त बनाएं। लेकिन ऊपर-सामने ठीक है, जब तक यह ईमानदार है और, अधिमानतः, स्प्रिंट से पहले किया जाता है।
    पीडीआर

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

    6

    सबसे पहले, कहानियों / कार्यों के बीच निर्भरता और कहानी / कार्य के दायरे / प्रयास में अनिश्चितता के बीच एक बड़ा अंतर है।

    निर्भरता कार्य / कहानी को उस कार्य / कहानी की तुलना में कम प्राथमिकता देकर निर्भर करती है, जिस पर यह निर्भर करता है और संभवतः एक एनोटेशन है कि यह दूसरे कार्य / कहानी के शुरू होने से पहले शुरू नहीं हो सकता है।

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

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

    अंत में, स्क्रेम में, यह टीम है जो कुछ देने का वादा करती है। अगर वह वादा पूरा नहीं किया जा सकता है, तो यह पूरी टीम की विफलता है, टीम के भीतर कभी किसी व्यक्ति की नहीं।


    यह भी एक अच्छा जवाब था। अगर मैं दो उत्तरों को सही के रूप में चिह्नित कर सकता हूं तो मेरे पास होगा।
    एलन

    3

    स्प्रिंट प्लानिंग के दौरान मुझे एक जंगली अनुमान लगाना पड़ा कि इस अपरिभाषित उपयोगकर्ता की कहानी में कितना समय लगेगा।

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

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


    धन्यवाद दर्जर। हाँ स्क्रैम मास्टर प्रोजेक्ट मैनेजर भी है। स्क्रैम मास्टर ने कहा है कि न्यूनतम योजना और प्रलेखन होना है। इसके बजाय हम सुविधाओं का निर्माण कर रहे हैं जैसा कि हम जाते हैं, स्प्रिंट के दौरान नित्य समीक्षा के साथ पुनरावृत्ति / परिवर्तन जो कि परियोजना मन्जर द्वारा निर्धारित किया गया था (इसलिए डिजाइन और कार्यान्वयन एक ही स्प्रिंट में होता है)। एक भूमिका से आने के बाद जहां डिजाइन काफी ठोस था सामने, मैं मुश्किल से इस कोड-बाय-द वायर संस्कृति को समायोजित कर रहा हूं।
    एलन

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

    @PhillW। हमारे पास तैयार की परिभाषा नहीं है। हमारे पास एक विशेषता के लिए अलग-अलग राज्यों के साथ बैकलॉग है। जैसे ही हम बाहर जाते हैं, डिटेल निकल जाता है हो गया आधिकारिक तौर पर जब हितधारक हस्ताक्षर करते हैं लेकिन वास्तव में वह मील के पत्थर के लिए है और यह प्रबंधक / स्क्रैम मास्टर / निर्माता (एक ही व्यक्ति) है जो कहता है कि यह कब किया जाता है। मैं अब एक साल के लिए "स्क्रैम" कर रहा हूं, शुरू करने के लंबे समय बाद तक मैंने स्क्रैम पर कुछ आत्म अध्ययन नहीं किया क्योंकि मुझे लगा कि हमारा तरीका अजीब था। जितना अधिक मैंने पढ़ा, मुझे लगा कि हम "कार्गो पंथ" स्क्रैम कर रहे हैं। लेकिन राजनीति मेरे लिए इसके बारे में कुछ भी करना मुश्किल बना देती है ...
    एलन

    1

    क्या डिजाइन के बारे में कार्य कहानियों के रूप में व्यक्त किए गए हैं और आपकी टीम की परिभाषाएं क्या हैं

    • एक कहानी तैयार है
    • एक कहानी की है

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

    यदि कोई कहानी तैयार नहीं है, तो उसे अपने स्प्रिंट में एम्बेड न करें। यदि स्वीकृति की शर्त पूरी नहीं होती है, तो यह खत्म नहीं हुआ है।

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

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


    0

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

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

    कुछ और प्रशिक्षण नुकसान नहीं कर सकते हैं ... शायद डिजाइनर के साथ काम करना आपके लिए कुछ नए यूएक्स कौशल हासिल करने का अवसर होगा? ... कि गिलास को आधा-खाली होने के बजाय आधा भरा हुआ देखा जा रहा है :))

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