पैटन जेफ. प्रयोक्ता कहानियां। फुर्तीली सॉफ्टवेयर विकास की कला

अमूर्त

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

उपयोगकर्ता कहानी मानचित्रण की एक प्रमुख तकनीक विचारों और प्रदर्शनों को संरचित करना है क्योंकि उपयोगकर्ता प्रक्रिया के माध्यम से आगे बढ़ता है।

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

इसकी जरूरत किसे है?

आईटी विश्लेषकों और परियोजना प्रबंधकों के लिए. एक अवश्य पढ़ने की बात। पढ़ने में आसान और आनंददायक, पुस्तक आकार में मध्यम है।

समीक्षा करें

अपने सरलतम रूप में, यह इसी प्रकार काम करता है।

एक आगंतुक कैफे में आता है, व्यंजन चुनता है, ऑर्डर देता है, भोजन प्राप्त करता है, खाता है और भुगतान करता है।

हम प्रत्येक चरण में सिस्टम से जो चाहते हैं उसके लिए आवश्यकताएँ लिख सकते हैं।

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

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

हम व्यक्तित्व बनाते हैं, उन्हें सहानुभूति के लिए विवरण देते हैं, और व्यक्तित्व के पक्ष से कहानियाँ बताना शुरू करते हैं।

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

और एक व्यवसाय भी है (एक संगठनात्मक चरित्र एक संगठन के हितों का प्रतिनिधित्व करने वाला चरित्र है)। व्यवसाय औसत जांच बढ़ाना, खरीदारी की आवृत्ति बढ़ाना और मुनाफा बढ़ाना चाहते हैं। विचार यह है - आइए कुछ व्यंजनों के असामान्य व्यंजन पेश करें। एक और विचार - आइए नाश्ते का परिचय दें।

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

दर्जनों कहानियाँ. अगला प्राथमिकताकरण और बैकलॉग है? जेफ उन समस्याओं की ओर इशारा करते हैं जो उत्पन्न होती हैं: छोटे विवरणों में उलझ जाना और वैचारिक समझ खोना, साथ ही कार्यक्षमता को प्राथमिकता देना लक्ष्यों के साथ असंगतता के कारण एक खराब तस्वीर बनाता है।

लेखक का पथ: हम कार्यक्षमता को नहीं, बल्कि परिणाम को प्राथमिकता देते हैं = उपयोगकर्ता को अंत में क्या मिलता है।

एक स्पष्ट गैर-स्पष्ट बिंदु: प्राथमिकता सत्र पूरी टीम द्वारा नहीं किया जाता है, क्योंकि यह अप्रभावी है, बल्कि तीन लोगों द्वारा किया जाता है। पहला व्यवसाय के लिए ज़िम्मेदार है, दूसरा उपयोगकर्ता अनुभव के लिए और तीसरा कार्यान्वयन के लिए।

आइए हम एक उपयोगकर्ता की समस्या को हल करने के लिए न्यूनतम (न्यूनतम व्यवहार्य समाधान) का चयन करें।

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

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

इस तरह से विस्तार प्रक्रियाओं के अनुपालन में अखंडता बनाता है।

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

फिर मूल्यांकन के लिए विवरण है। इसके लिए तीन लोग काफी हैं. उपयोगकर्ता अनुभव, डेवलपर, पसंदीदा प्रश्न वाले परीक्षक के लिए जिम्मेदार: "क्या होगा अगर..."।

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

क्या लेखक की राय में दस्तावेज़ीकरण आवश्यक है? हाँ मुझे चाहिए। लेकिन नोट्स के रूप में जो आपको यह याद रखने की अनुमति देते हैं कि आप किस बात पर सहमत थे। किसी बाहरी व्यक्ति को शामिल करने पर फिर से चर्चा की आवश्यकता है।

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

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

जब कार्यान्वयन कई टीमों में किया जाता है तो एक कहानी मानचित्र संचार को बेहतर बनाने में मदद करता है। मानचित्र पर क्या होना चाहिए? बातचीत जारी रखने के लिए आपको क्या चाहिए. केवल एक उपयोगकर्ता कहानी (कौन, क्या, क्यों) नहीं, बल्कि विचार, तथ्य, इंटरफ़ेस रेखाचित्र, आदि...

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

हम प्रक्रिया मानचित्र पर कहानियाँ सुनाते हैं।

एक कर्मचारी दोपहर के भोजन के लिए आया.

वह क्या चाहता है? सेवा की गति. ताकि उसका दोपहर का भोजन पहले से ही मेज पर या कम से कम एक ट्रे पर उसका इंतजार कर रहा हो। उफ़ - एक ग़लत कदम: कर्मचारी खाना चाहता था। उन्होंने लॉग इन किया और बिजनेस लंच विकल्प चुना। उन्होंने आहार में मदद करने और वजन न बढ़ने देने के लिए कैलोरी सामग्री और पोषण सामग्री देखी। उन्होंने यह तय करने के लिए पकवान की तस्वीरें देखीं कि वह उस स्थान पर खाना खाएंगे या नहीं।

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

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

प्रक्रिया के प्रत्येक चरण में, आपको किसी तरह कार्यक्षमता प्रदान करने की आवश्यकता है; इसके लिए आपको किसी व्यक्ति को आधार के रूप में लेना होगा और चुनना होगा कि उसके लिए क्या अधिक महत्वपूर्ण है (वही तीन चयनकर्ता)। कहानी का अंत तक अनुसरण किया = एक व्यवहार्य समाधान निकाला।

इसके बाद विवरण आता है। ग्राहक यह देखना चाहता है कि कैफे कितना व्यस्त है, ताकि कतारों में धक्का-मुक्की न करनी पड़े। आख़िर वह क्या चाहता है?

जब वह वहां पहुंचेगा तो 15 मिनट में कितने लोग होंगे इसका पूर्वानुमान देखें

किसी कैफे में औसत सेवा समय और उसकी गतिशीलता आधे घंटे पहले देखें

स्थिति और टेबल अधिभोग की गतिशीलता देखें

यदि पूर्वानुमान प्रणाली अस्पष्ट परिणाम दे या काम करना बंद कर दे तो क्या होगा?

वीडियो के माध्यम से कैफे में कतारों के साथ-साथ टेबलों पर कब्जे को देखें। हम्म, पहले ऐसा क्यों नहीं करते?!

लेखक अभ्यास के लिए एक छोटा सा अभ्यास बताता है: कल्पना करने का प्रयास करें कि आप सुबह उठने के बाद क्या करते हैं। एक कार्ड = एक क्रिया. कार्यान्वयन की विधि पर नहीं, बल्कि लक्ष्य पर ध्यान केंद्रित करते हुए, व्यक्तिगत विवरण हटाने के लिए कार्डों को बड़ा करें (कॉफी पीसने के बजाय, एक स्फूर्तिदायक पेय पिएं)।

यह पुस्तक किसके लिए है: आईटी विश्लेषकों और परियोजना प्रबंधकों के लिए। एक अवश्य पढ़ने की बात।

क्षुधा

3 से 5 लोगों के समूह में चर्चा और निर्णय लेना प्रभावी होता है।

पहले कार्ड पर लिखें कि क्या विकसित करने की आवश्यकता है, दूसरे पर - पहले में आपने जो किया उसे सही करें, तीसरे पर - पहले और दूसरे में जो किया गया उसे सही करें।

केक की तरह कहानियाँ तैयार करें - कोई रेसिपी लिखकर नहीं, बल्कि यह पता लगाकर कि केक किसके लिए, किस अवसर के लिए और कितने लोगों के लिए है। यदि हम बिक्री को विभाजित करें, तो यह केक, क्रीम इत्यादि के उत्पादन में नहीं, बल्कि छोटे तैयार केक के उत्पादन में होगी।

सॉफ्टवेयर विकास एक फिल्म बनाने के समान है, जब आपको फिल्मांकन शुरू होने से पहले स्क्रिप्ट को सावधानीपूर्वक विकसित और बेहतर बनाने, दृश्य, अभिनेताओं आदि को व्यवस्थित करने की आवश्यकता होती है।

संसाधनों की कमी सदैव बनी रहेगी।

20% प्रयास ठोस परिणाम देते हैं, 60% अकल्पनीय परिणाम देते हैं, 20% प्रयास हानिकारक होते हैं - इसलिए सीखने पर ध्यान केंद्रित करना महत्वपूर्ण है न कि नकारात्मक परिणाम की स्थिति में निराशा।

उपयोगकर्ता के साथ सीधे संवाद करें, स्वयं को उसकी जगह पर महसूस करें। कुछ समस्याओं पर ध्यान दें.

मूल्यांकन के लिए कहानी का विवरण देना और विकसित करना स्क्रम का सबसे नीरस हिस्सा है, चर्चाओं को एक्वेरियम मोड में खड़ा करें (बोर्ड में 3-4 लोग चर्चा करते हैं, अगर कोई भाग लेना चाहता है, तो वह किसी को बदल देता है)।

स्रोत: www.habr.com