कस्टम अनुप्रयोगों के लिए एक अच्छी प्रोग्रामिंग पद्धति क्या है जिसे बहुत तेज और बहुत अनुकूलित कोडित करने की आवश्यकता है? मुझे एहसास है कि आवश्यकताओं की कमी एक समस्या है चाहे कोई फर्क नहीं पड़ता। इसके अलावा आप अपने अभ्यासों को बदलने के लिए प्रबंधन को कैसे समझते हैं? अगला सवाल यह है कि आप लोगों को 5000 लाइन एकल फ़ाइल प्रोग्राम लिखना बंद करने के लिए कैसे प्राप्त करते हैं?बहुत तेज समयरेखा और छोटी आवश्यकताओं के लिए सर्वश्रेष्ठ प्रोग्रामिंग पद्धति?
आपके द्वारा पूछे जाने वाले एक से अधिक प्रश्न हैं।
Scrum अच्छा है परियोजनाओं के इन प्रकार पर उपयोग करने के लिए। यह प्रबंधन करने का एक तरीका प्रदान करने में बहुत अच्छा है कि आप समय पर परियोजना कर सकते हैं या आप इसे अपनी सभी सुविधाओं के साथ प्राप्त कर सकते हैं, लेकिन आपके पास दोनों नहीं हो सकते हैं।
"इस तरह की परियोजनाओं"? स्क्रम बहुत अच्छा है, और मैं इसे दिल से अनुशंसा करता हूं, लेकिन मैं ओपी को यह कहने से शर्मिंदा हूं कि कोई भी फुर्तीली पद्धति इस परियोजना को किसी भी अच्छे काम करेगी। यह लंबे समय तक "चुस्त" शब्द को खराब कर देता है। –
कम से कम स्क्रम के साथ आप प्रति स्प्रिंट की आवश्यकताओं के एक छोटे से सेट को प्रतिबद्ध करने के लिए प्रबंधन प्राप्त कर सकते हैं। और उस पर आप उन्हें बता सकते हैं कि एक सभ्य गुणवत्ता पर स्प्रिंट में क्या किया जा सकता है। या तो वे इसे स्वीकार करते हैं या ... नरक की तरह दौड़ते हैं। –
बल का प्रयोग करें।
लेकिन गंभीरता से, यह Death March जैसा लगता है। भाग जाओ।
स्क्रम मेरा अनुमान होगा लेकिन ध्यान रखें कि स्क्रम को बहुत अनुशासित टीम के सदस्यों की आवश्यकता होती है। दस्तावेज करने की आदत में जाएं कि आपको कौन सी आवश्यकताएं मिलती हैं और उन्हें एक स्थान पर रखें ताकि प्रबंधन सहित सभी लोग इसका उपयोग कर सकें। अंत में, कार्यों का पूर्वानुमान करने का एक उचित तरीका ढूंढें और प्रबंधन के सामने रखें ताकि वे टीम के सभी की वर्तमान प्राथमिकताओं को जान सकें। मैं पिछले साल के लिए एक बहुत ही समान वातावरण में रहा हूं और दुर्भाग्य से मुझे जादू बुलेट नहीं मिला है।
लेखन 5000 लाइन प्रोग्राम बेहद आलस्य का संकेत है। हमने हाल ही में एक लड़के को जाने दिया क्योंकि पहले उसने 5000 लाइन जावा कक्षाओं के साथ शुरू किया था, फिर वह एक कन्स्ट्रक्टर (चर नहीं) में चर शुरू करने के लिए प्रयास/पकड़ विवरणों का उपयोग करने में चला गया। कुछ रचनात्मक आलोचना के साथ 5000 लाइन कार्यक्रम लिखने वाले व्यक्ति को प्रेरित करने का एक तरीका खोजें। ऐसा लगता है कि यह इसके दिल में एक प्रबंधन मुद्दा है।
उचित कस्टम विकास जैसा कुछ भी करने का सबसे तेज़ तरीका आपके साथ और ग्राहक इसे एक साथ विकसित कर रहा है। प्रतिक्रिया तुरंत है, और वे वास्तव में देख सकते हैं कि क्या शामिल है। अन्यथा, आप अपने अधिक सुविधाजनक ध्यान के लिए बस व्यापार की गति कर रहे हैं। इसके अलावा, चूंकि वे सीधे आपके साथ काम करते हैं, इसलिए वे आपके प्रबंधन में आपकी रक्षा कर सकते हैं।
हालांकि, बिना किसी संदर्भ के, मुझे दूसरों से सहमत होना है और कहना है कि यह शायद सबसे अधिक करियर-निर्माण की स्थिति नहीं है।
यदि "आवश्यकताओं की कमी" वास्तव में तथ्य है, तो आपको एक परियोजना भी शुरू नहीं करनी चाहिए। मुझे विश्वास है कि आपका मतलब क्या है "अस्पष्ट या अनिश्चित आवश्यकताओं"। यदि यह आपका मामला है, तो Agile प्रक्रिया वह है जिसे आपको विचार करना चाहिए। एक्सपी, स्क्रम या क्रिस्टल। स्क्रम निस्संदेह सबसे हल्के वजन वाली फुर्तीली प्रक्रिया है।
प्रबंधन इंजीनियरों से अलग दिमाग हो सकता है, लेकिन आप यह नहीं कह सकते कि प्रबंधन गलत है और उनके अभ्यासों को बदला जाना चाहिए। समझ और पते के संघर्ष को बेहतर बनाने के लिए बस संवाद करें।
लोगों को अपठनीय कोड लिखने से रोकने के लिए, लोगों को संक्षिप्त तरीके से कोड लिखने के लिए प्रशिक्षित करने का सबसे अच्छा तरीका है। जोड़ी प्रोग्रामिंग और निरंतर कोड समीक्षा एक अच्छा समाधान हो सकता है।
एक सामान्य नियम के रूप में आप एक परियोजना के तीन घटक, समय, गुणवत्ता और मनी है।
ऐसा लगता है कि आपका ग्राहक/मालिक समय को नियंत्रित करना चाहता है ... और उसे एक और नियंत्रण करना चाहिए, दूसरा जिसे आप नियंत्रित करते हैं।
तो यदि वह समय और गुणवत्ता को नियंत्रित करना चाहता है तो उसे आपको और/या आपकी टीम को उस अतिरिक्त समय के लिए अधिक पैसा देना होगा, यदि आप समय और धन को नियंत्रित करना चाहते हैं, तो आप नियंत्रण प्राप्त कर सकते हैं गुणवत्ता, जो इस मामले में कम हो जाएगा।
हम हमेशा अपने ग्राहकों को क्या कहते हैं कि वे इसे प्राप्त कर सकते हैं या वे अब इसे प्राप्त कर सकते हैं, लेकिन वे अभी यह नहीं कर सकते हैं!
मुझे नहीं लगता कि पद्धति बहुत मायने रखती है ... असली मुद्दा समय है।
कुछ भी नया नहीं है!
जो मुझे बहुत अच्छी तरह से काम करने के लिए मिला वह Evolutionary Prototyping नामक एक आरएडी तकनीक है।
सबसे अच्छा तरीका ग्राहक के बारे में आपके विचार को लागू करना है, फिर उसे प्रस्तुत करें, उसकी टिप्पणियां प्राप्त करें और तदनुसार अपना कार्यान्वयन अनुकूलित करें। जब ग्राहक अंततः संतुष्ट हो जाता है, तो आपका इम्प्लांटेशन किया जाता है। अब मजेदार हिस्सा आता है: इसे दस्तावेज करें!
स्क्रम या एक्सपी इन परिस्थितियों में बहुत अच्छी तरह से काम करता है; यदि आप "मूल" प्रणाली के लिए कुछ न्यूनतम आवश्यकताओं को पूरा कर सकते हैं और उस पर निर्माण कर सकते हैं, तो आप इस तथ्य पर प्रतिक्रियाशील हो सकते हैं कि जब भी सामने की आवश्यकताओं को प्रदान किया जाता है, तो वे लगभग हमेशा गलत होते हैं।
जो लोग 5000 लाइन एकल फ़ाइल प्रोग्राम लिखते हैं वे अनुशासित और खराब प्रोग्रामर हैं। चूंकि एक्सपी और स्क्रम दोनों को एक प्रणाली बनाने के लिए अनुशासन की आवश्यकता होती है जिसे बनाए रखा और बनाया जा सकता है, मुझे यकीन नहीं है कि अगर आप के साथ काम करना है तो मुझे कैसे आगे बढ़ना है। मेरा अनुमान कम से कम उन्हें अपने तरीकों की गलत समझाने का प्रयास करेगा।
मुझे गालिया होने का मतलब नहीं है, लेकिन ऐसा लगता है कि अधिकांश लोगों के जवाब के साथ उलझन में आ गए हैं। अधिकांश उत्तर प्रोग्रामिंग विधियों के बजाए प्रोजेक्ट मैनेजमेंट मेटाहेडोलॉजी के आसपास होते हैं।
आपकी स्थिति को देखते हुए मुझे लगता है कि एससीआरयूएम और फुर्तीली विधियों (जैसे ओपन यूपी) परियोजना प्रबंधन दृष्टिकोण से ठीक काम करेंगे। असल में मैं सिर्फ एससीआरयूएम के साथ रहूंगा क्योंकि ऐसा लगता है कि आपकी परियोजना के चारों ओर संरचना के रास्ते में बहुत कुछ नहीं है। यह चीजों को अच्छी और दुबला रखेगा और कार्यों पर ध्यान केंद्रित करना चाहिए। आपको बस यह सुनिश्चित करने की ज़रूरत है कि आप एससीआरयूएम के कुछ बुनियादी नियमों का पालन करें जो आपके कार्यों की पहचान कर रहे हैं, अपने कार्यों का अनुमान लगा सकते हैं, अपने कार्यों का वर्णन कर सकते हैं, अपने पुनरावृत्तियों की योजना बना सकते हैं और यदि संभव हो तो एक स्प्रिंट को पीछे छोड़ दें। यदि आप समय पर वास्तव में तंग हैं तो मुझे यकीन है कि आप इसे छोड़ सकते हैं।
अपने वास्तविक सवाल का जवाब करने के लिए (के रूप में मैं यह वैसे भी देखें), मैं आप अपने डिजाइन तंत्र के रूप में सीआरसी (सी लड़की आर esponsibiltiy सी ollaborator) कार्ड का उपयोग कर एक डोमेन आधारित दृष्टिकोण अपनाने का सुझाव देते हैं। मुझे लगता है कि आपके एप्लिकेशन में कुछ सीमित डोमेन है, जिसमें यह मौजूद है, यानी लेखा, स्टॉक प्रबंधन इत्यादि। डोमेन में मौजूद वस्तुओं में आपके डोमेन को विघटित करने का प्रयास करें यानी वास्तविक स्टॉक ऑब्जेक्ट्स जैसे "स्टॉक आइटम", "चालान" , "डिलीवरी" इत्यादि। फिर इनमें से प्रत्येक ऑब्जेक्ट एक सीआरसी कार्ड बनाते हैं जहां आप इसका नाम परिभाषित करते हैं, इसकी जिम्मेदारियां और अन्य वर्ग जो इसके उत्तरदायित्वों को पूरा करने के लिए सहयोग करते हैं। फिर आप अपने आवेदन में इन सीआरसी कार्ड का प्रतिनिधित्व करने के लिए वास्तविक कक्षाएं लिखते हैं।
किसी भी प्रबंधक को प्रत्यय, या कोरिडिनेटर या उन पंक्तियों के साथ कुछ भी बनाने से बचें।आपको किस डोमेन के साथ समाप्त होना चाहिए, वह डोमेन का प्रतिनिधित्व करने वाली वस्तुओं का एक सेट है जिसे आप उस डोमेन में होने वाली किसी भी प्रकार की गतिविधि करने के लिए बड़े पैमाने पर रिफैक्टरिंग की आवश्यकता के साथ आसानी से संशोधित कर सकते हैं। आप आसानी से बदलते आवश्यकताओं के साथ इस तरह के समाधान को अनुकूलित कर सकते हैं क्योंकि डोमेन ऑब्जेक्ट्स स्थिर रहना चाहिए जबतक कि आप अधिक ऑब्जेक्ट्स या आपके डोमेन को विस्तृत नहीं कर रहे हों।
आशा है कि यह आपके लिए उपयोग में है।
ओके स्क्रम दिलचस्प लग रहा है ... क्या यह लागू किया जा सकता है जब कार्यालय अलग-अलग स्थानों पर हों?
यह एक आम बात है जब आप अर्ध-कंप्यूटर-साक्षर ग्राहकों से निपटते हैं। – slashmais
आप एक में 4 प्रश्न पूछते हैं। मैं उन्हें विभाजित करने का प्रस्ताव करता हूं, और आपको शायद विशिष्ट उत्तर मिलते हैं। इसके अलावा आप अधिक प्रतिष्ठा कमा सकते हैं ;-) –
हाँ, इस सवाल को विभाजित करना एक अच्छा विचार होगा! – Yarik