चुस्त शिक्षण या चंचल और आईटी शिक्षा के बीच क्या आम है

अच्छा समय, हभवें।

मैं "मोबाइल उपकरणों पर उपयोगिता इंजीनियरिंग और सर्वव्यापी कम्प्यूटिंग" ट्रैक के दौरान उत्पन्न टिप्पणियों को साझा करना चाहता हूं, जिसे संयुक्त रूसी-जर्मन छात्र स्कूल JASS-2012 के हिस्से के रूप में आयोजित किया गया था, जिसके बारे में उन्होंने पहले से ही हब पर लिखा था हालांकि, पिछले पोस्ट के विपरीत, मैं आयोजक की आंखों के माध्यम से स्कूल का वर्णन करूंगा।

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

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

परियोजना की शुरुआत

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

अपनी गलती का एहसास होने के बाद, हमने प्रारंभिक योजनाओं का पालन नहीं करने का फैसला किया - अगर हमें चुस्त रहना था, तो हर चीज में चुस्त रहना होगा, और हमने एक मंथन सत्र से परियोजनाओं के काम पर काम शुरू किया।

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



अंततः, कुछ बेहतर विचार बाकी हैं। यह कहने योग्य है कि इस तरह के वोट की प्रक्रिया में, हमने नई परियोजनाओं के संश्लेषण का अवलोकन किया। कुछ विचार इतने करीब थे कि संयुक्त होने पर वे एक और सामान्य परियोजना के कार्य (विशेषताएं) बन गए।

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

आवश्यकताओं

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

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

प्रक्रिया है

चूंकि हमारे पास विकास और प्रशिक्षण के लिए बहुत सीमित समय था, इसलिए छात्रों को कई प्रकार की घबराहट वाली रैलियों (रैली - अंग्रेजी बैठक, बैठक से) का परीक्षण करने का निर्णय लिया गया था।

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

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

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

अध्यात्म विद्या

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

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

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

निष्कर्ष

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

हमें अराजक शिक्षण का विचार इतना पसंद आया कि हमने आगामी SECR सम्मेलन में इस विषय पर एक छोटी संयुक्त रिपोर्ट बनाने की योजना बनाई।

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