चरम प्रोग्रामिंग तकनीक और सिद्धांत

एक्सट्रीम प्रोग्रामिंग (XP) लचीली सॉफ्टवेयर डेवलपमेंट मेथडोलॉजी में से एक है। कार्यप्रणाली के लेखक केंट बेक, वार्ड कनिंघम, मार्टिन फाउलर और अन्य हैं।

योजना का खेल

हमारी दुनिया बहुत अस्थिर और अप्रत्याशित है ताकि स्थिति की स्थिरता पर भरोसा किया जा सके। सॉफ़्टवेयर विकसित करते समय एक ही बात होती है: हम एक दुर्लभ प्रणाली के बारे में कह सकते हैं कि इसका अंतिम रूप विकास की शुरुआत में विस्तार से जाना जाता था। आमतौर पर, ग्राहक की भूख खाने के साथ आती है: वह लगातार कुछ बदलना चाहता है, कुछ सुधार करना चाहता है, और कुछ को पूरी तरह से सिस्टम से बाहर फेंक देता है। यह आवश्यकताओं की परिवर्तनशीलता है जिससे हर कोई इतना डरता है। सौभाग्य से, एक व्यक्ति को संभावित विकल्पों की भविष्यवाणी करने की क्षमता दी जाती है और इस प्रकार, स्थिति को नियंत्रण में रखें।
चरम प्रोग्रामिंग में, नियोजन विकास का एक अभिन्न अंग है और यह तथ्य कि योजनाएँ बदल सकती हैं, को शुरू से ही ध्यान में रखा जाता है। Fulcrum, एक ऐसी तकनीक जो आपको स्थिति की भविष्यवाणी करने की अनुमति देती है और दर्द रहित रूप से परिवर्तन के साथ रखा जाता है, नियोजन का एक खेल है। इस तरह के खेल के दौरान, आप जल्दी से ज्ञात सिस्टम आवश्यकताओं को इकट्ठा कर सकते हैं, उनका विकास कर सकते हैं और प्राथमिकता के अनुसार उनके विकास की योजना बना सकते हैं।
किसी भी अन्य खेल की तरह, योजना के प्रतिभागियों और उसके लक्ष्य हैं। मुख्य आंकड़ा ग्राहक का है। यह वह है जो एक विशेष कार्यक्षमता की आवश्यकता की रिपोर्ट करता है। प्रोग्रामर प्रत्येक कार्यक्षमता का एक सांकेतिक मूल्यांकन देते हैं। नियोजन के खेल की सुंदरता डेवलपर और ग्राहक के बीच उद्देश्य और एकजुटता की एकता में निहित है: जीत के मामले में, हर कोई जीतता है, हार के मामले में, हर कोई हारता है। लेकिन एक ही समय में, प्रत्येक प्रतिभागी अपने तरीके से जीत जाता है: ग्राहक बजट के अनुसार सबसे महत्वपूर्ण कार्यों का चयन करता है, और प्रोग्रामर उनके कार्यान्वयन के लिए उनकी क्षमताओं के अनुसार कार्यों का मूल्यांकन करता है।
चरम प्रोग्रामिंग यह मानती है कि डेवलपर्स खुद के लिए तय करने में सक्षम हैं कि वे अपने कार्यों से कब तक सामना करेंगे और उनमें से कौन एक समस्या को हल करने के लिए अधिक इच्छुक होगा और कौन।
एक आदर्श स्थिति में, ग्राहक और एक प्रोग्रामर को शामिल करने की योजना बनाने का एक खेल अगले विकास पुनरावृत्ति शुरू होने से पहले हर 3-6 सप्ताह में आयोजित किया जाना चाहिए। यह आपको पिछली पुनरावृत्ति की सफलताओं और विफलताओं के अनुसार काफी आसानी से समायोजन करने की अनुमति देता है।

रिलीज की योजना

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

Iteration योजना

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

स्टैंडिंग मीटिंग

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

आराम

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

रूपक प्रणाली

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

साइट पर ग्राहक

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

विकास से पहले परीक्षण

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

जोड़ी प्रोग्रामिंग

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

स्थिति में बदलाव

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

सामूहिक कोड स्वामित्व

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

कोडिंग समझौता

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

बार-बार एकीकरण

जब भी संभव हो, डेवलपर्स को हर कुछ घंटों में अपने कोड को एकीकृत और जारी करना चाहिए। किसी भी मामले में, आपको कभी भी एक दिन से अधिक समय तक बदलाव नहीं रखना चाहिए। बार-बार एकीकरण विकास और विकास में विखंडन से बचा जाता है जब डेवलपर्स विचारों के आदान-प्रदान या पुन: उपयोग कोड के संदर्भ में संवाद नहीं कर सकते। सभी को नवीनतम संस्करण के साथ काम करना चाहिए।
डेवलपर्स के प्रत्येक जोड़े को एक उचित अवसर मिलते ही अपना कोड देना चाहिए। यह तब हो सकता है जब सभी यूनिटटेस्ट 100% पास हो जाए। दिन में कई बार परिवर्तन प्रस्तुत करने से, आप एकीकरण समस्याओं को लगभग शून्य कर देते हैं। एकीकरण "अभी भुगतान करें या बाद में भुगतान करें" प्रकार की एक गतिविधि है। इसलिए, छोटे भागों में प्रतिदिन होने वाले परिवर्तनों को एकीकृत करते हुए, आपको परियोजना की डिलीवरी से तुरंत पहले एक पूरे सिस्टम में बाँधने के लिए एक सप्ताह बिताने की आवश्यकता का सामना नहीं करना पड़ेगा। हमेशा सिस्टम के नवीनतम संस्करण पर काम करें।

चालीस घंटे काम सप्ताह

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

निष्कर्ष

इन तकनीकों को एक कारण के लिए एक साथ नहीं लाया जाता है। उनका सुसंगत संयोजन बौद्धिक प्रतिध्वनि में विकास प्रक्रिया को शुरू करने में सक्षम है, उत्पाद की गुणवत्ता में काफी वृद्धि करता है और इसके रिलीज के समय को करीब लाता है। — ; , ; .

:

• Wikipedia
• / . , . — .: , 2004. – 368 .: .