पॅटन जेफ. वापरकर्ता कथा. चपळ सॉफ्टवेअर विकासाची कला

सार

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

वापरकर्ता कथा मॅपिंगचे मुख्य तंत्र म्हणजे कल्पना आणि कार्यप्रदर्शनाची रचना करणे हे वापरकर्ता प्रक्रियेतून पुढे जातो.

त्याच वेळी, प्रक्रियेचे वर्णन वेगवेगळ्या प्रकारे केले जाऊ शकते. तुम्ही एक महत्त्वाचे मूल्य प्राप्त करताच तुम्ही पावले तयार करू शकता किंवा तुम्ही वापरकर्त्यांच्या कामाच्या दिवसाची कल्पना करू शकता आणि सिस्टम वापरत असताना त्याची कल्पना करू शकता. प्रक्रिया नकाशावर वापरकर्त्याच्या कथेच्या रूपात बोलल्या जाव्यात, प्रक्रियांची रूपरेषा सांगणे आवश्यक आहे या वस्तुस्थितीवर लेखक लक्ष केंद्रित करतो, ज्याने आम्हाला वापरकर्ता कथा नकाशा हे नाव दिले.

कोणाला याची गरज आहे

आयटी विश्लेषक आणि प्रकल्प व्यवस्थापकांसाठी. आवर्जून वाचावे. वाचण्यास सोपे आणि आनंददायक, पुस्तक आकाराने मध्यम आहे.

अभिप्राय

त्याच्या सर्वात सोप्या स्वरूपात, हे कसे कार्य करते.

एक अभ्यागत कॅफेमध्ये येतो, पदार्थ निवडतो, ऑर्डर देतो, अन्न घेतो, खातो आणि पैसे देतो.

आम्‍ही प्रत्‍येक टप्प्यावर सिस्‍टमकडून आम्‍हाला हव्या असलेल्या आवश्‍यकता लिहू शकतो.

सिस्टमने डिशची यादी दर्शविली पाहिजे, प्रत्येक डिशची रचना, वजन आणि किंमत आहे आणि ते कार्टमध्ये जोडण्यास सक्षम असावे. आम्हाला या आवश्यकतांवर विश्वास का आहे? हे आवश्यकतांच्या "मानक" वर्णनात वर्णन केलेले नाही आणि यामुळे जोखीम निर्माण होते.

ज्या कलाकारांना हे का आवश्यक आहे हे समजत नाही ते सहसा चुकीचे काम करतात. कल्पना तयार करण्याच्या प्रक्रियेत सहभागी नसलेले कलाकार निकालात गुंतलेले नाहीत. चपळ म्हणतो, चला मुख्यत्वे सिस्टमवर नाही तर लोकांवर, ग्राहकांवर, त्यांची कार्ये आणि ध्येयांवर लक्ष केंद्रित करूया.

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

कार्यालयातील कर्मचारी जाखर जेवायला गेला आणि त्याला लवकर नाश्ता करायचा आहे. त्याला काय गरज आहे? कल्पना अशी आहे की त्याला बहुधा बिझनेस लंच हवा आहे. दुसरी कल्पना अशी आहे की त्याला सिस्टमने त्याची प्राधान्ये लक्षात ठेवावीत, कारण तो आहारावर आहे. दुसरी कल्पना. त्याला लगेच त्याच्यासाठी कॉफी आणायची आहे कारण त्याला दुपारच्या जेवणापूर्वी कॉफी पिण्याची सवय आहे.

आणि एक व्यवसाय देखील आहे (संस्थात्मक वर्ण म्हणजे संस्थेच्या हिताचे प्रतिनिधित्व करणारे एक पात्र). व्यवसायांना सरासरी चेक वाढवायचा आहे, खरेदीची वारंवारता वाढवायची आहे आणि नफा वाढवायचा आहे. कल्पना अशी आहे - चला काही पाककृतींचे असामान्य पदार्थ देऊया. दुसरी कल्पना - चला नाश्ता सादर करूया.

कल्पना वापरकर्त्याच्या कथेच्या स्वरूपात एकत्रित, रूपांतरित आणि सादर केल्या जाऊ शकतात आणि केल्या पाहिजेत. Zakhar बिझनेस सेंटरचा एक कर्मचारी म्हणून, प्रणालीने मला ओळखावे असे मला वाटते जेणेकरुन मला माझ्या प्राधान्यांवर आधारित मेनू मिळू शकेल. एक वेटर म्हणून, मला सिस्टमने मला सूचित करावे की टेबलवर कधी जावे जेणेकरून क्लायंट जलद सेवेबद्दल समाधानी असेल. वगैरे.

डझनभर कथा. पुढे प्राधान्यक्रम आणि अनुशेष? जेफ उद्भवणार्‍या समस्यांकडे लक्ष वेधतात: लहान तपशीलांमध्ये अडकणे आणि वैचारिक समज गमावणे, तसेच कार्यक्षमतेला प्राधान्य देणे हे उद्दिष्टांशी विसंगततेमुळे एक विस्कळीत चित्र तयार करते.

लेखकाचा मार्ग: आम्ही कार्यक्षमतेला प्राधान्य देत नाही, परंतु परिणाम = वापरकर्त्याला शेवटी काय मिळते.

एक स्पष्ट गैर-स्पष्ट मुद्दा: प्राधान्य सत्र संपूर्ण टीमद्वारे केले जात नाही, कारण ते कुचकामी आहे, परंतु तीन लोकांद्वारे. पहिला व्यवसायासाठी, दुसरा वापरकर्त्याच्या अनुभवासाठी आणि तिसरा अंमलबजावणीसाठी जबाबदार आहे.

एक वापरकर्ता समस्या सोडवण्यासाठी किमान निवडू या (किमान व्यवहार्य उपाय).

प्रक्रियेच्या प्रत्येक टप्प्यावर लोकांना आणि भागधारकांना काय आवश्यक आहे ते टीमला सांगून आणि चर्चा करून आम्ही वापरकर्ता कथा, डिझाइन स्केचेस, मर्यादा आणि व्यवसाय नियम वापरकर्ता कथा नकाशावर वापरून प्रथम प्राधान्य कल्पना तपशीलवार करतो. आम्ही उर्वरित कल्पना संधींच्या अनुशेषात तपासल्याशिवाय सोडतो.

प्रक्रिया डावीकडून उजवीकडे कार्डांवर लिहिलेली आहे, प्रक्रियेच्या पायऱ्यांखालील कार्ड्सवर कल्पना आहेत. परस्पर समंजसपणा सुनिश्चित करण्यासाठी संपूर्ण कथेच्या मार्गावर कार्यसंघ सदस्यांसह एकत्र चर्चा करणे अत्यावश्यक आहे.

अशा प्रकारे विस्ताराने प्रक्रियांच्या अनुपालनामध्ये अखंडता निर्माण होते.

प्राप्त कल्पनांची चाचणी घेणे आवश्यक आहे. नॉन-टीम मेंबर व्यक्तीची टोपी घालतो आणि व्यक्तीचा दिवस त्याच्या डोक्यात जगतो, त्याची समस्या सोडवतो. हे शक्य आहे की तो घडामोडी पाहत नाही, पुन्हा कार्ड तयार करतो आणि संघ स्वतःसाठी पर्याय शोधतो.

त्यानंतर मूल्यमापनासाठी तपशील आहे. यासाठी तीन लोक पुरेसे आहेत. वापरकर्त्याच्या अनुभवासाठी जबाबदार, विकसक, आवडत्या प्रश्नासह परीक्षक: “काय तर...”.

प्रत्येक टप्प्यावर, चर्चा वापरकर्त्याच्या इतिहासाच्या प्रक्रियेच्या नकाशाचे अनुसरण करते, जे वापरकर्त्याचे कार्य लक्षात ठेवून सुसंगत समज निर्माण करण्यास अनुमती देते.

लेखकाच्या मते कागदपत्रे आवश्यक आहेत का? होय, मला त्याची गरज आहे. परंतु आपण काय मान्य केले आहे हे लक्षात ठेवण्याची परवानगी देणारी नोट्स म्हणून. बाहेरील व्यक्तीला पुन्हा सहभागी करून घेण्यासाठी चर्चा आवश्यक आहे.

लेखक चर्चेच्या गरजेवर लक्ष केंद्रित करून दस्तऐवजीकरणाच्या पर्याप्ततेच्या विषयात सखोलपणे जात नाही. (होय, दस्तऐवजीकरण आवश्यक आहे, ज्यांना चपळपणाची सखोल माहिती नाही अशा लोकांचा दावा कितीही फरक पडत नाही). तसेच, क्षमतेच्या केवळ काही भागाचा विस्तार केल्याने संपूर्ण प्रणालीचे संपूर्ण पुनर्कार्य करण्याची आवश्यकता निर्माण होऊ शकते. जेव्हा कल्पना चुकीची असेल तेव्हा लेखकाने केसमध्ये जास्त विस्ताराचा धोका दर्शविला आहे.

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

जेव्हा अनेक संघांमध्ये अंमलबजावणी केली जाते तेव्हा कथा नकाशा संवाद सुधारण्यास मदत करतो. नकाशावर काय असावे? संभाषण चालू ठेवण्यासाठी आपल्याला काय आवश्यक आहे. केवळ वापरकर्ता कथा (कोण, काय, का) नाही तर कल्पना, तथ्ये, इंटरफेस स्केचेस इ..

इतिहासाच्या नकाशावरील कार्डे अनेक क्षैतिज ओळींमध्ये विभाजित करून, आपण कार्य रिलीझमध्ये विभाजित करू शकता - बेअर किमान हायलाइट करा, वाढत्या कार्यक्षमतेचा स्तर आणि धनुष्य.

आम्ही प्रक्रिया नकाशावर कथा सांगतो.

एक कर्मचारी जेवणासाठी आला.

त्याला काय हवे आहॆ? सेवा गती. जेणेकरून त्याचे दुपारचे जेवण आधीच टेबलवर किंवा किमान ट्रेवर त्याची वाट पाहत आहे. अरेरे - चुकलेली पायरी: कर्मचाऱ्याला खायचे होते. त्याने लॉग इन केले आणि बिझनेस लंचचा पर्याय निवडला. त्याने कॅलरी सामग्री आणि पौष्टिक सामग्री पाहिली ज्यामुळे त्याला आहार आणि वजन वाढू नये. त्या ठिकाणी जेवायचे की नाही हे ठरवण्यासाठी त्याने डिशची चित्रे पाहिली.

पुढे, तो लंच आणि डिनर घेण्यासाठी जाईल का? किंवा कदाचित दुपारचे जेवण त्याच्या कार्यालयात वितरित केले जाईल? मग प्रक्रियेची पायरी म्हणजे खाण्यासाठी जागा निवडणे. त्याला ते केव्हा वितरित केले जाईल आणि त्याची किंमत किती असेल हे त्याला पहायचे आहे, म्हणून तो आपला वेळ आणि शक्ती कुठे घालवायची ते निवडू शकतो - खाली जाणे किंवा कामावर जाणे. त्याला रांगेत धक्काबुक्की होऊ नये म्हणून कॅफे किती व्यस्त आहे हे पहायचे आहे.

त्यानंतर कर्मचारी कॅफेमध्ये आला. त्याला त्याचा ट्रे बघायचा आहे म्हणून तो तो घेऊन थेट डिनरला जाऊ शकतो. सेवेवर पैसे कमवण्यासाठी कॅफेला पैसे स्वीकारायचे आहेत. कर्मचार्‍याला कॅफेसह सेटलमेंटवर कमीतकमी वेळ गमावायचा आहे, जेणेकरून मौल्यवान वेळ निरुपयोगीपणे वाया जाऊ नये. ते कसे करायचे? आगाऊ पैसे द्या किंवा त्याउलट सेवा नंतर दूरस्थपणे. किंवा किओस्क वापरून जागेवरच पैसे द्या. यात सर्वात महत्त्वाची गोष्ट काय आहे? बँकेच्या कार्डाने किती लोक दुपारच्या जेवणासाठी पैसे देण्यास तयार आहेत? रिपीट पेमेंटसाठी किती लोक या कॅन्टीनवर त्यांचा कार्ड नंबर ठेवण्यासाठी विश्वास ठेवतील? क्षेत्रीय संशोधनाशिवाय हे अस्पष्ट आहे, चाचणी आवश्यक आहे.

प्रक्रियेच्या प्रत्येक टप्प्यावर, आपल्याला कशाप्रकारे कार्यक्षमता प्रदान करणे आवश्यक आहे; यासाठी आपल्याला एखाद्या व्यक्तीस आधार म्हणून घेणे आवश्यक आहे आणि त्याच्यासाठी अधिक महत्त्वाचे काय आहे ते निवडणे आवश्यक आहे (तेच तीन निवडक). कथेचे शेवटपर्यंत अनुसरण केले = एक व्यवहार्य तोडगा काढला.

पुढे तपशील येतो. क्लायंटला कॅफे किती व्यस्त आहे हे पहायचे आहे, जेणेकरून रांगेत धक्का बसू नये. त्याला नक्की काय हवंय?

तो तिथे पोहोचल्यावर १५ मिनिटांत किती लोक असतील याचा अंदाज पाहा

कॅफेमधील सरासरी सेवा वेळ आणि त्याची गतीशीलता अर्धा तास अगोदर पहा

परिस्थिती आणि टेबल ऑक्युपन्सी डायनॅमिक्स पहा

जर अंदाज प्रणालीने अस्पष्ट परिणाम दिला किंवा काम करणे थांबवले तर?

व्हिडिओद्वारे कॅफेमधील रांगा, तसेच टेबलांची व्याप्ती पहा. हम्म, ते आधी का करू नये?!

लेखक सराव करण्यासाठी एक लहान व्यायाम दर्शवितो: सकाळी उठल्यानंतर तुम्ही काय करता याची कल्पना करण्याचा प्रयत्न करा. एक कार्ड = एक क्रिया. वैयक्तिक तपशील काढण्यासाठी कार्डे मोठे करा (कॉफी पीसण्याऐवजी, उत्साहवर्धक पेय प्या) अंमलबजावणीच्या पद्धतीवर लक्ष केंद्रित न करता, ध्येयावर लक्ष केंद्रित करा.

हे पुस्तक कोणासाठी आहे: आयटी विश्लेषक आणि प्रकल्प व्यवस्थापक. आवर्जून वाचावे.

अनुप्रयोग

3 ते 5 लोकांच्या गटामध्ये चर्चा आणि निर्णय घेणे प्रभावी आहे.

पहिल्या कार्डावर काय विकसित करणे आवश्यक आहे ते लिहा, दुसऱ्यावर - तुम्ही पहिल्यामध्ये काय केले ते दुरुस्त करा, तिसऱ्यावर - पहिल्या आणि दुसऱ्यामध्ये काय केले ते दुरुस्त करा.

केक सारख्या कथा तयार करा - रेसिपी लिहून नव्हे तर कोणासाठी, कोणत्या प्रसंगासाठी आणि किती लोकांसाठी केक आहे हे शोधून काढा. जर आपण विक्री खंडित केली तर ते केक, मलई इत्यादींच्या उत्पादनात नाही तर लहान तयार केकच्या उत्पादनात असेल.

सॉफ्टवेअर डेव्हलपमेंट हे चित्रपट बनवण्यासारखेच आहे, जेव्हा तुम्हाला चित्रीकरण सुरू होण्यापूर्वी स्क्रिप्ट काळजीपूर्वक विकसित करणे आणि पॉलिश करणे, दृश्य, कलाकार इत्यादी व्यवस्थित करणे आवश्यक आहे.

संसाधनांची कमतरता नेहमीच असेल.

20% प्रयत्न मूर्त परिणाम देतात, 60% अगम्य परिणाम देतात, 20% प्रयत्न हानिकारक असतात - म्हणूनच नकारात्मक परिणामाच्या बाबतीत निराश न होता शिकण्यावर लक्ष केंद्रित करणे महत्वाचे आहे.

वापरकर्त्याशी थेट संवाद साधा, स्वतःला त्याच्या शूजमध्ये अनुभवा. काही समस्यांवर लक्ष केंद्रित करा.

मूल्यमापनासाठी कथेचे तपशील देणे आणि विकसित करणे हा स्क्रॅमचा सर्वात भयानक भाग आहे, चर्चा एक्वैरियम मोडमध्ये करा (3-4 लोक मंडळावर चर्चा करतात, जर एखाद्याला भाग घ्यायचा असेल तर तो एखाद्याची जागा घेतो).

स्त्रोत: www.habr.com