आप किसी प्रोजेक्ट के लिए सॉफ़्टवेयर प्रक्रिया कैसे बनाते हैं?

13

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

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

development-process specifications

— थॉमस ओवेन्स
स्रोत

अच्छा-फास्ट-सस्ता-प्रक्रिया - जब कोई परियोजना पीछे हो जाती है, तो प्रक्रिया को रोक दें।

— ChuckCottrill

2

यह कैसे निकला?

— रॉबर्ट हार्वे

10

मैं आपको सुझाव दूंगा कि आप एजाइल प्रोग्रामिंग में देखें।

बहुत से संस्करण हैं, लेकिन उनमें कुछ चीजें समान हैं:

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

शुरू करने के लिए एक अच्छी जगह MSF एजाइल या स्क्रैम होगी ।

— कीथ
स्रोत

7

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

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

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

— थॉमस ओवेन्स

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

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

— थॉमस ओवेन्स

1

हम परियोजना प्रबंधन की प्रक्रियाओं के लिए प्रिंस 2 का उपयोग करते हैं , और यह बहुत अच्छी तरह से काम करता है। मेरा सुझाव है कि यह एक कंपनी के लिए किसी भी परियोजना प्रबंधन के साथ अत्याचारपूर्ण प्रतीत होगा, हालांकि!

— ColinYounger
स्रोत

1

हमने इस वीडियो में अपनी CI सर्वर के रूप में TeamCity का उपयोग करते हुए, अपनी स्वयं की जरूरतों के लिए उल्लिखित विकास पाइपलाइन को अनुकूलित किया।

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC एकमात्र CI प्रणाली है जिसके बारे में मुझे पता है कि पुल के बजाय एक रिपॉजिटरी-पुश करता है, जिसका अर्थ है (सैद्धांतिक रूप से) अब और नहीं टूटी हुई बिल्ड!

1

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

— जॉननो नोलन
स्रोत

0

MSBuild, CruiseControl.NET, FxCop, NUnit, NCover और तोड़फोड़ का उपयोग कर .NET प्रोग्रामिंग के लिए निरंतर एकीकरण पर इन लेखों की जाँच करें ...

सॉफ्टवेयर विकास खाइयों से

— जैक पीटरसन
स्रोत

1

@Zack: हम .NET प्रोग्रामिंग का उपयोग नहीं करते हैं। मैं सामान्य सलाह की तलाश कर रहा हूं जो कि किसी भी परियोजना पर किसी भी प्रौद्योगिकी स्टैक का उपयोग कर सकती है। किसी मॉडल को चुनना, उस मॉडल को लागू करना, इत्यादि जैसी चीजें।

— थॉमस ओवेन्स