मील का पत्थर और वेब विकास परियोजना का प्रबंधन

Question

मैं ट्रैक + एसवीएन को लागू करने की कोशिश कर रहा हूं। लेकिन एक परियोजना प्रबंधन मुद्दे का सामना कर रहा हूँ। आपको पृष्ठभूमि देने के लिए, मेरी अधिकांश परियोजनाएं वेब विकास से संबंधित हैं (वे डिजाइन, प्रोग्रामिंग, परीक्षण इत्यादि जैसे चरणों के माध्यम से जाते हैं)।

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

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

तो कहें कि मेरे पास एक ग्राहक है जिसका अंतिम समय सीमा एक्स तारीख है। फिर मैंने अपने मील का पत्थर 1.0 के रूप में समय सीमा के साथ सेट किया। लेकिन फिर मैं प्रोजेक्ट को साप्ताहिक कहां ट्रैक करूं? क्योंकि मैं रिलीज की तारीख से एक दिन पहले महसूस नहीं करना चाहता था कि इतना ज्यादा बचा है। मैं किसी भी तरह साप्ताहिक जांच करना चाहता हूँ।

इसके अलावा मैं खाता वृद्धि/बग भी टिकट के रूप में लेना चाहता हूं और उन्हें मील के पत्थर के रूप में एक साथ जोड़ना चाहता हूं।

Ive ने 1.x.x की तरह कुछ कल्पना की जहां पहला एक्स फीचर एन्हांसमेंट के समूह से मेल खाता है जबकि दूसरा एक्स बग फिक्स से मेल खाता है। क्या कोई बेहतर तरीका है? मैं इस तरह के सिस्टम में साप्ताहिक स्थिति कैसे प्रबंधित करूं?

क्या ऐसा करने का कोई मानक तरीका है? मैं इसकी शुरुआत कैसे करूं? पूरी तरह से उलझन में हूँ।

धन्यवाद।

Answer 1

अच्छा, यह निर्भर करता है। आपने यह निर्दिष्ट नहीं किया कि कितनी बड़ी परियोजना, कितने प्रोग्रामर काम करेंगे, आप कितनी बार वितरित करने की योजना बनाते हैं।

यह बताते हुए कि, हम कई वर्षों तक फैले एक बड़े प्रोजेक्ट पर ट्रैक का उपयोग करते हैं जिसमें छोटे सबप्रोजेक्ट्स की संख्या होती है।

• मील के पत्थर जहाँ हम subproject में कुछ विशेषताएं वितरण के लिए तैयार है बिंदुओं के रूप में परिभाषित कर रहे हैं। प्रत्येक सबप्रोजेक्ट में पहला मील का पत्थर आमतौर पर सबसे लंबा होता है। हम आमतौर पर मील का पत्थर "सबप्रोजेक्ट नाम v0.01" के रूप में नामित करते हैं। संस्करण केवल 0.01, 0.02, बढ़ते हैं ... जब हम सबप्रोजेक्ट के लिए अपेक्षित सब कुछ लागू करते हैं तो हम अंतिम मील का पत्थर v1.00 के रूप में चिह्नित करते हैं। बाद के बग फिक्स मील का पत्थर पर जाते हैं कि हम "सबप्रोजेक्ट नाम - v1.00 - बगफिक्स"

• मील का पत्थर विवरण में केवल नई सुविधाओं या बग फिक्स की सूची शामिल है। दस्तावेज़ीकरण विकी और टिकटों में लिखा गया है।

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

• टिकट में लागू होने वाली सुविधा या बग का विस्तृत विवरण शामिल है।

  • बग रिपोर्टिंग टिकट में बग का विवरण और पुन: उत्पन्न करने के लिए चरण (लगभग हमेशा) होते हैं।
  • फ़ीचर टिकटों में सुविधा का विस्तृत विवरण शामिल है जिसे कार्यान्वित किया जाना चाहिए। एक टिकट में 6 घंटे तक काम करता है। जब हम काम की योजना बनाते हैं, तो हम सुविधाओं को 1 से 6 घंटे के काम में विभाजित करते हैं। यदि हम अनुमान लगाते हैं कि उस सुविधा को अधिक समय की आवश्यकता है, तो हम इसे कई टिकटों में विभाजित करते हैं, इसलिए उनमें से प्रत्येक काम के 1-6 घंटे में फिट हो सकता है। हमने 6 घंटे उठाए क्योंकि हमें लगता है कि यह शीर्ष है कि हम 30% से अधिक त्रुटि के साथ अनुमान लगा सकते हैं (जिसका अर्थ यह है कि यह 6 घंटे का अनुमान लगभग 4-8 घंटे के बीच में किया जा सकता है)। बेशक, इस आंकड़ों से अपवाद हैं। हमारे अनुभव में, गलत अनुमानों का मुख्य कारण हमने खराब विनिर्देशों में लिखा है। वह, लगभग हमेशा होता है क्योंकि हम (डेवलपर्स) ने हमारे उपयोगकर्ताओं की व्यावसायिक आवश्यकताओं को गलत समझा।

• अनुमान और समय ट्रैकिंग के लिए कुछ ट्रैक प्लगइन्स हैं। इस पृष्ठ को देखें: http://trac.edgewall.org/wiki/TimeTracking। हम Timing And Estimation Plugin का उपयोग करते हैं। आप टिकट पर काम करने के लिए टिकट और समय के लिए अनुमानित समय दर्ज कर सकते हैं। फिर आप रिपोर्ट प्राप्त कर सकते हैं कि आपने टिकट/मील के पत्थर पर कितना समय बिताया और आपको कितना समय खत्म करने की आवश्यकता है।

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

Answer 2

अपने 1.0 मील का पत्थर डिलिवरेबल डेट पर सेट करना ठीक है, लेकिन आप पहले मील के पत्थर को परिभाषित करना चाहते हैं - यदि आप के लिए यह एक अच्छा अंतराल है, तो उन्हें साप्ताहिक बनाएं और उन्हें उचित रूप से नंबर दें। 4 सप्ताह की परियोजना के लिए, शायद 0.2, 0.5, 0.7, और 1.0 काम करेंगे। प्रत्येक मील का पत्थर पर प्रासंगिक बिट्स सूचीबद्ध करें: 'डिज़ाइन पूर्ण', 'कोडिंग पूर्ण', 'परीक्षण पूर्ण', आदि। यदि आप लक्ष्य पर नहीं हैं, तो वास्तविक परियोजना प्रबंधन कार्य शुरू होता है!

Answer 3

मुझे लगता है कि आपके पास कई विकल्प और कुछ निर्णय लेने हैं।

आप Feature Driven Development के बारे में सोच सकते हैं। संचार के समर्थन के लिए आप ट्रैक का उपयोग कर सकते हैं। मोटे अनाज वाले काम, बढ़िया टिकट और जल्दी रिलीज।

विकसित होने वाली सुविधाओं की एक सूची बनाएं और बताएं कि रिलीज, कहें ... संस्करण 1.0, तब होता है जब सभी सुविधाएं विकसित और परीक्षण की जाती हैं। सभी सुविधाओं के लिए छतरी टिकट बनाओ। मोटे अनाज हैं और विकास ताल परिभाषित करेंगे।

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

यदि विकास के दौरान बेहतर काम करने की आवश्यकता है, तो उन्हें बनाने में शर्मिंदा न हों। और छतरी कार्यों को इन नए टिकटों पर निर्भर करते हैं।

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

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

मेरा मानना ​​है कि ज्यादातर मामलों के लिए दो संख्या संस्करण संख्या पर्याप्त है। पहला नंबर संगतता और दूसरा, रिलीज दर्शाता है। लेकिन कई चर हैं जो संस्करण संख्या के अंदर हो सकते हैं: स्रोत संगतता, बाइनरी संगतता, बगफिक्स स्तर, रिलीज, साथी उत्पाद संस्करण (अला ऑरैक), प्रोटोकॉल संगतता, आदि

Answer 4

मैं साढ़े सालों से ट्रैक/एसवीएन का उपयोग कर रहा हूं।

यहाँ मैं क्या सुझाव दे सकता है: स्थापना के समय, विस्तार, संक्रमण (या उन्हें फोन जो चाहो)

बहुत पहले यात्रा के लिए योजना विशेषताएं: कई पुनरावृत्तियों में सॉफ़्टवेयर संस्करण का

• स्प्लिट उत्पादन। दूसरों वृद्धि की योजना बनाने और
• कार्य (टिकट) bugfixes एक टिकट प्रदान की अधिक से अधिक विस्तृत किया जाना चाहिए के लिए एक क्लाइंट-मूल्यवान प्रदेय
• बचत टिकट निर्माण पर समय एक अच्छा विचार नहीं है। अधिक दानेदार और छोटे कार्यों --- प्रगति पर अधिक नियंत्रण। इस प्रकार, योजना की कमियों की पूर्व खोज और प्रबंधन के लिए और अधिक समय।
• टिकट प्रगति पर भी विभाजित हो सकते हैं। यदि डेवलपर परिणाम तक पहुंच गया है जिसे ग्राहक को दिखाया जा सकता है लेकिन पूरा कार्य पूरा नहीं किया है, तो डेवलपर कार्य को विभाजित कर सकता है और पूरा भाग "बंद" या "हल" के रूप में चिह्नित कर सकता है जो कुछ और दानेदार नियंत्रण देता है।
• दैनिक प्रगति का पता लगाएं, नहीं साप्ताहिक (या कम से कम सप्ताह में कई बार)

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

Answer 5

सामने एक छोटी सी चेतावनी: मुझे ट्रैक ... या एसवीएन का उपयोग करने के बारे में कोई जानकारी नहीं है। मुझे लगता है कि आपके मील का पत्थर संस्करण नियंत्रण/बग ट्रैकिंग सिस्टम द्वारा निर्धारित नहीं किया जाना चाहिए।

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

मैं टीम के साथ काम करने के लिए शेड्यूल और कार्यों का उपयोग करता हूं। कार्य पूरा होने के रूप में कार्य करें। हर किसी के लिए मैं सिर्फ मील का पत्थर पर रिपोर्ट करता हूं। क्या हम 15 मई तक यूएटी बनाने जा रहे हैं? हाँ हम हैं।

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

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

कोई जादू फार्मूला नहीं है, लेकिन सैकड़ों कार्यों और हजारों मनुष्यों के साथ परियोजनाओं में केवल 4 मील का पत्थर हो सकते हैं।

alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

क्षमा करें यह सीधे Trac और SVN से संबंधित नहीं है, लेकिन उम्मीद है कि इस आप कैसे मील के पत्थर आम तौर पर इस्तेमाल कर रहे हैं पर एक मोटा अनुमान देती। ओह और कॉमिक सैन्स के अत्यधिक उपयोग के लिए अग्रिम माफी ... यक।