फुर्तीली कार्यप्रणाली का उपयोग करके सॉफ्टवेयर को फिर से लिखना


13

मान लीजिए आपको एजाइल मेथोडोलॉजी का उपयोग करके एक संपूर्ण एप्लिकेशन को फिर से लिखना है, तो आप यह कैसे करेंगे?

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

इसके अलावा, आप कब रिलीज करना शुरू करेंगे? एजाइल का कहना है कि हमें जल्दी और अक्सर रिलीज़ करना चाहिए, लेकिन पूर्ण पुनर्लेखन पूरा होने से पहले इसे रिलीज़ करने का कोई मतलब नहीं है।


4
एक पूरे आवेदन को फिर से लिखना एक अच्छा विचार नहीं है। नेटस्केप को फिर से लिखना देखें । एक पूरे आवेदन को फिर से लिखने में बहुत कुछ खो जाता है। ज्ञान स्रोत में संहिताबद्ध है और फिर से लिखना होगा। कोड पर आना और घोषणा करना आसान है "उन्होंने ऐसा क्यों किया?" मैं इसे बेहतर और कम लाइनों में कर सकता हूं! बहुत बार, एक बार कोड में डेवलपर समझता है कि यह पहले इस तरह से क्यों लिखा गया था। कोड सादगी वार्ता
चक कॉनवे

प्रश्न पूछना इंगित करता है कि आपके पास एगाइल के साथ इतने बड़े उपक्रम के लिए प्रभावी रूप से उपयोग करने का अनुभव नहीं है। व्यक्तिगत रूप से मैं यह कैसे करूंगा ("भाग जाना" प्रश्न से बाहर था) मेरे जोखिम को सीमित करने और क्षति नियंत्रण रणनीतियों को लागू करने से शुरू होता है (जब) ​​यह नाशपाती के आकार का हो जाता है।
3

आपको नहीं लगता कि इस पूरे पुनर्निर्माण की प्रक्रिया के दौरान नए requirments बनाए जाएंगे?
जेएफओ

SO से क्रॉस-पोस्ट किया गया: stackoverflow.com/questions/13168314/…
gnat

पूरे आवेदन को फिर से लिखना नहीं होगा बहुत संयुक्त राष्ट्र?
Pieter B

जवाबों:


15

इसे उच्च-स्तरीय महाकाव्यों में विभाजित करें। आवेदन के प्रत्येक कार्यात्मक क्षेत्र को लें, एक समय में एक कदम।

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

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

एक बार जब आप उत्पादन के लिए एक घटक जारी करते हैं, तो अगले पर जाएं।


@Pdr ने क्या कहा।
KodeKreachor

3
गैर-उत्पादन रिलीज़ अवधि के दौरान, अनुप्रयोग को डॉगफ़ूड करें, भले ही एक वीएम में, उपयोग और पूर्णता के लिए एक महसूस करने के लिए, क्योंकि सभी आवश्यकताओं को सामने से जाना जाता है और विकास टीम के भीतर महत्वपूर्ण डोमेन / बीआई से अधिक होने की संभावना है।
जस्टिनसी

10

हम सिर्फ इस तरह के एक अनुभव के माध्यम से मिला (मुझे उत्पाद स्वामी के रूप में)। किसी चीज को हासिल करने में हमें दो साल लग गए। लेकिन फिर भी, फुर्तीलेपन ने हमें कई फायदे दिए।

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

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

  • पुराने उत्पाद के उपयोगकर्ताओं को वर्गीकृत करें। उन उपयोगकर्ताओं की पहचान करें, जिन्हें केवल पुराने उत्पाद का एक छोटा सा हिस्सा चाहिए और फिर भी इससे कुछ उपयोगी हो सकता है। वे आपके पहले महाकाव्य को परिभाषित करते हैं।

  • फिर ऐसे महाकाव्य जोड़ें जो अन्य श्रेणी के उपयोगकर्ताओं को नए उत्पाद पर ले जाने की अनुमति दें। आदि जब तक आपके पास एक बैक लॉग नहीं है जो सभी उपयोगकर्ताओं को कवर करता है।

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

  • जब आपके पास 20-50 महाकाव्य हैं, तो टीम का अनुमान है।

  • उपयोगकर्ता कहानियों में शीर्ष सबसे महाकाव्यों को विभाजित करें जो टीम स्प्रिंट के भीतर संभव होने का विश्वास करती है। अभी तक सभी महाकाव्यों के लिए ऐसा न करें, केवल शीर्ष पर। बाकी के बंटवारे के लिए आपके पास बहुत समय होगा।

बाहरी रूप से कब जारी करें! यह एक व्यावसायिक निर्णय है। कम से कम यह दृष्टिकोण आपको कुछ उपयोगकर्ता श्रेणियों के लिए पहले जारी करने का अवसर देता है। यह आसान हो सकता है अगर प्रबंधन इस बात से घबरा जाता है कि यह परियोजना कभी खत्म नहीं होगी।


4
A total rewrite is by nature not agile at all. You should instead consider refactoring the existing product piece by piece.Truer शब्द कभी नहीं बोला गया।
maple_shaft

4

अब जारी करें यदि आप कर सकते हैं

जब आप कोड जारी करना शुरू करते हैं, तो आपका प्रश्न एक महान है। मुझे लगता है कि दो प्रोविजन्स लागू होते हैं। पहला, आपके पास "अच्छी पर्याप्त गुणवत्ता" है, और दूसरा यह कि आप एमवीपी (न्यूनतम व्यवहार्य उत्पाद) के लिए आवश्यकताओं को पूरा करते हैं।

रोम (और चंचल) एक दिन में निर्मित नहीं थे

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

एक बूट बूटस्ट्रैपर बनें

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

क्यों जल्दी और अक्सर रिलीज?

जल्दी रिलीज और अक्सर कई कारणों से एक मंत्र है। यह हमारे विचार विमर्श को जीवन देता है कि उत्पाद क्या बनना चाहिए, यह वास्तविक बनाता है कि हम कहां हैं, और यह हमें पुनरावृत्त / वृद्धिशील परिवर्तनों के लिए एक आधार देता है। रिलीज की गति बहुत अधिक चपलता के लिए एक अपरिवर्तनीय है, अंतर के साथ जो रिलीज को प्राप्त करता है (ग्राहक सरोगेट या अंतिम उपयोगकर्ता)। चुस्त होने से पहले, रखरखाव का अनुमान सॉफ्टवेयर सिस्टम की लागत का 60% था। यह प्रबंधकों और अन्य लोगों के लिए बहुत अड़चन का स्रोत है, कुछ लोग जो उत्पाद रिलीज को महसूस करते हैं, जहां सॉफ्टवेयर मरने के लिए जाता है। उनके लिए, रिलीज के बाद सब कुछ फिर से काम करना और एक उत्पाद को ठीक करने के लिए भुगतान करना है जो उन्होंने एक बार पहले ही भुगतान किया था।

विमोचन पूर्व अप्राकृतिक है

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

पिछली टीम की आलोचना न करें

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

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

आप एक बात भूल गए। पुरानी टीम ने ग्राहकों की उम्मीदों को निर्धारित किया। आपको उन्हें बहुत बेहतर तरीके से रीसेट करना होगा, या चीजों को ठीक उसी तरह करना होगा। स्टार्ट बटन न होने के लिए विंडोज 8 को कितना प्रेस किया गया है, फिर भी आईओएस और एंड्रॉइड ने कभी नहीं किया और किसी ने भी इसका उल्लेख करने के लिए नहीं सोचा।
4

2

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

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

"मान लीजिए आपको एजाइल मेथोडोलॉजी का उपयोग करके एक संपूर्ण एप्लिकेशन को फिर से लिखना है, तो आप इसे कैसे करेंगे?"

प्रश्न एक झूठे आधार पर आधारित है - कि एक फिर से लिखना चंचल माना जा सकता है।


2

इस बात पर विचार करें कि क्या आप एक बार में फिर से लिखे गए आवेदन को जारी कर सकते हैं, और इसे पुराने के साथ-साथ उत्पादन पक्ष में रख सकते हैं।

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

डेस्कटॉप एप्लिकेशन अधिक जटिल हो सकते हैं, लेकिन यह अक्सर संभव होगा।

आप सीम की तलाश कर रहे हैं - ऐसी जगहों के लिए जहां पुरानी प्रणाली के लिए अपनी पूर्ण ज़िम्मेदारी की आवश्यकता के बिना नई ज़िम्मेदारियों को निभाना संभव है।

शायद कुछ स्व-निहित व्यावसायिक तर्क हैं जिन्हें एक नई वेब सेवा या ढांचे में स्थानांतरित किया जा सकता है, और पुराने ऐप को इसके पुराने कोड के बजाय संशोधित उपयोग किया जा सकता है। बस जो कुछ बचा है उसे सीम पर बंद नक्काशी करते रहें, एक काटने में सभी प्रबंधनीय है।

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


1

एजाइल का कहना है कि हमें जल्दी और अक्सर रिलीज़ करना चाहिए, लेकिन पूर्ण पुनर्लेखन पूरा होने से पहले इसे रिलीज़ करने का कोई मतलब नहीं है।

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

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

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

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