प्याटन जेफ। प्रयोगकर्ता कथाहरू। एजाइल सफ्टवेयर विकास को कला

एनोटेसन

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

प्रयोगकर्ता कथा म्यापिङ को एक प्रमुख प्रविधि विचार र प्रदर्शन को संरचना को रूप मा प्रयोगकर्ता प्रक्रिया को माध्यम बाट जान्छ।

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

कसलाई यसको आवश्यक छ

आईटी विश्लेषकहरू र परियोजना प्रबन्धकहरूको लागि। पढ्नै पर्ने एउटा । पढ्न सजिलो र रमाइलो, पुस्तक आकार मा मध्यम छ।

प्रतिक्रिया

यसको सरल रूप मा, यो कसरी काम गर्दछ।

एक आगन्तुक क्याफेमा आउँछ, भाँडा छान्छ, अर्डर दिन्छ, खाना पाउँछ, खान्छ, र भुक्तानी गर्छ।

हामी प्रत्येक चरणमा प्रणालीबाट के चाहन्छौं त्यसका लागि आवश्यकताहरू लेख्न सक्छौं।

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

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

हामी व्यक्तित्वहरू सिर्जना गर्छौं, तिनीहरूलाई समानुभूतिको लागि विवरण दिन्छौं, र व्यक्तित्वको पक्षबाट कथाहरू सुनाउन थाल्छौं।

अफिसका कर्मचारी जाखर खाजा खान गए र छिटो खाजा खान चाहन्छन्। उसलाई के चाहिन्छ? विचार यो हो कि उसले सायद व्यापार लंच चाहन्छ। अर्को विचार यो हो कि ऊ प्रणालीले आफ्नो प्राथमिकताहरू सम्झन चाहन्छ, किनभने ऊ आहारमा छ। अर्को विचार। उसलाई तुरुन्तै कफी ल्याइयोस् भन्ने चाहना छ किनभने उसलाई खाजा अघि कफी पिउने बानी छ।

र त्यहाँ एक व्यवसाय पनि छ (एक संगठनात्मक चरित्र एक संगठन को चासो को प्रतिनिधित्व एक चरित्र हो)। व्यवसायहरू औसत जाँच बढाउन, खरिदहरूको आवृत्ति बढाउन र नाफा बढाउन चाहन्छन्। विचार यो छ - केहि व्यञ्जन को असामान्य व्यञ्जन प्रस्ताव गरौं। अर्को विचार - नाश्ता परिचय गरौं।

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

दर्जनौं कथा। अर्को प्राथमिकता र ब्याकलग हो? जेफले उत्पन्न हुने समस्याहरू औंल्याए: साना विवरणहरूमा अल्झिएर र वैचारिक बुझाइ गुमाउनु, साथै कार्यात्मकतालाई प्राथमिकता दिँदा लक्ष्यहरूसँग असंगतताको कारणले एउटा ठुलो चित्र सिर्जना गर्दछ।

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

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

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

हामी प्रक्रियाको प्रत्येक चरणमा मानिसहरू र सरोकारवालाहरूलाई के चाहिन्छ भनेर टोलीसँग बताएर र छलफल गरेर प्रयोगकर्ता कथाहरू, डिजाइन स्केचहरू, अवरोधहरू र व्यापार नियमहरू प्रयोगकर्ता कथा नक्सामा प्रयोग गरेर पहिलो प्राथमिकता विचारहरू विस्तार गर्छौं। हामी बाँकी विचारहरूलाई अवसरहरूको ब्याकलगमा जाँच नगरी छोड्छौं।

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

यस तरिकामा विस्तारले प्रक्रियाहरूको अनुपालनमा अखण्डता सिर्जना गर्दछ।

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

त्यसपछि मूल्याङ्कनको लागि विवरणहरू छन्। यसको लागि तीन जना पर्याप्त छन्। प्रयोगकर्ता अनुभव, विकासकर्ता, मनपर्ने प्रश्नको साथ परीक्षकको लागि जिम्मेवार: "के हो भने ..."।

प्रत्येक चरणमा, छलफलले प्रयोगकर्ताको इतिहासको प्रक्रिया नक्सालाई पछ्याउँछ, जसले प्रयोगकर्ताको कार्यलाई ध्यानमा राखेर सुसंगत समझ सिर्जना गर्न अनुमति दिन्छ।

लेखकको विचारमा कागजात आवश्यक छ? हो, मलाई यो चाहिन्छ। तर तपाईंले केमा सहमति जनाउनुभयो भन्ने कुरा सम्झन अनुमति दिने नोटहरूको रूपमा। बाहिरी व्यक्तिलाई पुन: छलफल गर्न आवश्यक छ।

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

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

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

इतिहास नक्सामा कार्डहरूलाई धेरै तेर्सो रेखाहरूमा विभाजन गरेर, तपाईंले कामलाई रिलीजहरूमा विभाजन गर्न सक्नुहुन्छ - नग्न न्यूनतम हाइलाइट गर्नुहोस्, कार्यक्षमता र धनुषहरूको तह बढाउनुहोस्।

हामी प्रक्रिया नक्सामा कथाहरू बताउँछौं।

एक कर्मचारी खाजा खान आयो ।

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

अर्को, के उसले लंच र डिनर लिन जान्छ? वा सायद लंच उनको कार्यालयमा डेलिभर गरिनेछ? त्यसपछि प्रक्रियाको चरण भनेको खानाको लागि ठाउँ छनौट गर्नु हो। उसलाई यो कहिले डेलिभर हुन्छ र यसको लागत कति पर्छ भनेर हेर्न चाहन्छ, त्यसैले उसले आफ्नो समय र शक्ति कहाँ खर्च गर्ने छनोट गर्न सक्छ - तल जाँदै वा काममा जाँदै। उनी क्याफेमा कत्तिको व्यस्त छ भनेर हेर्न चाहन्छन् ताकि लाममा बस्न नपरोस्।

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

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

अर्को विवरण आउँछ। ग्राहकले क्याफेमा कत्तिको व्यस्त छ भनेर हेर्न चाहन्छ, ताकि लाममा बस्न नपरोस्। उसले वास्तवमा के चाहन्छ?

उसले त्यहाँ पुग्दा १५ मिनेटमा कति मानिस होलान् भन्ने भविष्यवाणी हेर्नुहोस्

क्याफेमा औसत सेवा समय र यसको गतिशीलता आधा घण्टा अगाडि हेर्नुहोस्

स्थिति र तालिका कब्जा गतिशीलता हेर्नुहोस्

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

भिडियो मार्फत क्याफेमा लामहरू, साथै टेबलहरूको कब्जा हेर्नुहोस्। हम्म, त्यो पहिले किन नगर्ने ?!

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

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

अनुप्रयोगहरू

३ देखि ५ जनाको समूहमा छलफल र निर्णय प्रभावकारी हुन्छ।

पहिलो कार्डमा के विकास गर्न आवश्यक छ, दोस्रोमा लेख्नुहोस् - तपाईंले पहिलोमा के गर्नुभयो सही गर्नुहोस्, तेस्रोमा - पहिलो र दोस्रोमा के गरियो सही गर्नुहोस्।

केकहरू जस्तै कथाहरू तयार गर्नुहोस् - नुस्खा लेखेर होइन, तर कसलाई, कुन अवसरको लागि, र कति व्यक्तिहरूको लागि केक हो भनेर पत्ता लगाएर। यदि हामीले बिक्रीलाई तोड्यौं भने, यो केक, क्रिम, आदिको उत्पादनमा होइन, तर साना रेडिमेड केकको उत्पादनमा हुनेछ।

सफ्टवेयरको विकास भनेको चलचित्र बनाउनु जस्तै हो, जब तपाइँले छायांकन सुरु गर्नु अघि स्क्रिप्टलाई सावधानीपूर्वक विकास र पालिश गर्न आवश्यक छ, दृश्य, अभिनेताहरू, आदि व्यवस्थित गर्न आवश्यक छ।

त्यहाँ सधैं स्रोतको अभाव हुनेछ।

20% प्रयासले मूर्त नतिजा दिन्छ, 60% ले बुझ्न नसकिने नतिजा दिन्छ, 20% प्रयासहरू हानिकारक हुन्छन् - त्यसैले नकारात्मक नतिजा आएमा निराश नभई सिक्नमा ध्यान केन्द्रित गर्नु महत्त्वपूर्ण छ।

प्रयोगकर्तासँग सीधा कुराकानी गर्नुहोस्, आफूलाई उसको जुत्तामा महसुस गर्नुहोस्। केही समस्याहरूमा ध्यान दिनुहोस्।

मूल्याङ्कनको लागि कथाको विवरण र विकास गर्नु स्क्रमको सबैभन्दा डरलाग्दो भाग हो, छलफललाई एक्वैरियम मोडमा खडा बनाउनुहोस् (3-4 व्यक्तिहरू बोर्डमा छलफल गर्छन्, यदि कसैले भाग लिन चाहन्छ भने, उसले कसैलाई प्रतिस्थापन गर्दछ)।

स्रोत: www.habr.com