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

अमूर्त

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

उपयोगकर्ता कहानी के नक्शे की मुख्य तकनीक विचारों और कथनों की संरचना है क्योंकि उपयोगकर्ता प्रक्रिया से गुजरता है।

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

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

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

याद

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

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

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

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

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

हम लोगों को बनाते हैं, सहानुभूति के लिए हम उन्हें विवरण देते हैं और लोगों की ओर से हम कहानियों को सेट करना शुरू करते हैं।

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

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

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

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

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

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

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

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

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

इस तरह से एक्सपोजर प्रक्रिया मिलान के लिए अखंडता बनाता है।

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

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

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

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

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

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

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

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

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

कर्मचारी लंच के लिए आया।

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

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

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

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

आगे विस्तार है। ग्राहक कैफे का कार्यभार देखना चाहता है ताकि कतारों में गड़बड़ी न हो। वास्तव में वह क्या चाहता है?

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

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

स्थिति और तालिकाओं के रोजगार की गतिशीलता देखें

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

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

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

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

क्षुधा

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

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

केक जैसी कहानियां तैयार करें - बनाने की रेसिपी नहीं लिख रहे हैं, बल्कि यह पता लगा रहे हैं कि किस कारण से, कितने लोगों के पास केक है। यदि आप कार्यान्वयन को तोड़ते हैं, तो केक, क्रीम आदि के निर्माण पर नहीं, बल्कि छोटे तैयार केक के निर्माण पर।

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

संसाधन हमेशा दुर्लभ होंगे।

20% प्रयास मूर्त परिणाम देते हैं, 60% देते हैं यह स्पष्ट नहीं है कि, 20% प्रयास हानिकारक हैं - यही कारण है कि नकारात्मक परिणाम की स्थिति में सीखने पर ध्यान केंद्रित करना और निराशा न करना महत्वपूर्ण है।

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

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