मैनुअल - आज तक कैसे?

Question

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

Comments

क्या हम मुद्रित या ऑन-लाइन मैनुअल बात कर रहे हैं? कम से कम कुछ अलग-अलग रूप हैं जो यह ले सकते हैं।

— जेबी किंग

ऑनलाइन (पीडीएफ) नियमावली

— ब्रायन

Answer 1

मैं मैनुअल को अपडेट करूंगा:

1. प्रत्येक प्रमुख रिलीज के लिए, और
2. जब महत्वपूर्ण नई सुविधाएँ स्थिर और परिपक्व हो जाती हैं, तो आप जानते हैं कि वे हर पाँच मिनट में बदलने वाले नहीं हैं।

Answer 2

किसी भी समय कोड परिवर्तन से मैन्युअल रूप से निर्देशों को बदल दिया जाएगा - पीडीएफ (पीडीएफ) मैनुअल को अपडेट करें - बस रिलीज प्रक्रिया के मैनुअल हिस्से को अपडेट करें

यदि उपयोगकर्ता उत्पाद का उपयोग करने के तरीके के बारे में बताने के लिए मैनुअल पर भरोसा करते हैं, और उत्पाद बदल जाता है, तो यह केवल सामान्य ज्ञान है कि मैनुअल के संबंधित खंड को भी बदलना चाहिए

Comments

इसलिए यदि कोई तकनीकी लेखक कर्मचारियों पर नहीं है, तो इसे स्वयं अपडेट करें?

— ब्रायन

@ 0A0D - यदि आपके पास एक लेखक नहीं है, तो आपके पास ज्यादा विकल्प नहीं हैं, जब तक कि परीक्षण या सहायक कर्मचारी नहीं हैं जो यह कर सकते हैं।

— जेएफओ

मेरे पास अपनी परियोजनाओं के हिस्से के रूप में दस्तावेज़ 'स्रोत फाइलें' हैं। वे हमेशा कोड के रूप में एक ही समय में अपडेट किए जाते हैं। उन्हें रिलीज़ के साथ संस्करण दिया गया है और परियोजना फाइलों के बाकी हिस्सों (मर्क्युरियल!) के रूप में एक ही स्रोत मैंग्मनेट टूल का उपयोग करने में कामयाब रहे। मेरे पास एक परियोजना के साथ जाने के लिए मैनुअल का एक सुंदर मानक सेट है और ये सभी एक ही तरीके से प्रबंधित होते हैं (उपयोगकर्ता गाइड, कॉन्फ़िगरेशन / इंस्टॉलेशन गाइड, रिलीज़ नोट्स और हमारे अपने तकनीकी रेफरी / कल्पना दस्तावेज़)।

Answer 3

2010 में हम अभी भी छपे हुए दस्तावेज़ों की बात कर रहे हैं? क्यों? ;)

सभी गंभीरता में, प्रलेखन (या तो "एफ 1" अनुप्रयोग सहायता, पीडीएफ, या ऑनलाइन प्रलेखन) हर एक रिलीज का हिस्सा होना चाहिए। शून्य के बहाने। यह "प्रकाशित करना" सरल है। तथ्य की बात के रूप में, IMO, नियमित रूप से (ऑनलाइन और पीडीएफ) पर प्रलेखन अद्यतन नहीं करने के लिए कोई बहाना नहीं है, यहां तक ​​कि रिलीज के बीच में, जैसे ही मुद्दों को जाना जाता है और ठीक किया जाता है। इसे क्यूए के समान स्तर की आवश्यकता नहीं है - पास भी नहीं।

Answer 4

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

अपने DoD में प्रलेखन के अद्यतन को एकीकृत करें (की गई परिभाषा )

यह सुनिश्चित करेगा कि आपका दस्तावेज़ प्रत्येक उपयोगकर्ता कहानी के पूरा होने पर अद्यतित होगा।

हमारे द्वारा लिखी गई परिभाषा यहाँ दी गई है। मैंने मूल स्वरूप को बनाए रखने की कोशिश की, ताकि आपको विचार मिल सके। यह व्हाइटबोर्ड पर डाला गया ए 4 पेज है।

---------- 8 <------------ कट यहां ------------ 8 <----------

परक्राम्य नहीं

"हो गया" की परिभाषा

• 80% यूनिट टेस्ट कवरेज के साथ कोड, रिपॉजिटरी में प्रतिबद्ध

• यदि लागू हो तो स्क्रीनशॉट (1024x728, 395x281, 170x121 और 729x329)

• फ़ीचर विवरण यदि लागू हो (50 वर्ण, 100 वर्ण)

• पूर्ण अंत उपयोगकर्ता प्रलेखन

• क्या नई फ़ाइल ठीक से अद्यतन किया गया है

---------- 8 <------------ कट यहां ------------ 8 <----------

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

इस तरह से डेऑन की परिभाषा का एक फायदा यह है कि आपका उत्पाद प्रत्येक उपयोगकर्ता की कहानी के पूरा होने पर संभावित रूप से shippable है ।

इस एक के साथ संयोजन में इस तकनीक का उपयोग करें ।

Answer 5

मेरे संगठन में, हमारे पास आमतौर पर 3 प्रकार के रिलीज़ होते हैं:

1. इंजीनियरिंग रिलीज - कुछ विशिष्ट ग्राहक के लिए मूल रूप से गर्म फिक्स या केवल किसी विशेष ग्राहक ने तत्काल आधार पर अनुरोध किया है।
2. मामूली रिलीज - बग फिक्स, वृद्धिशील समर्थन
3. प्रमुख रिलीज - नई सुविधा का समर्थन आदि।

परिभाषा के अनुसार, मेजर रिलीज़ के पास ऑनलाइन और ऑफलाइन दोनों जगह प्रासंगिक दस्तावेज होना चाहिए। हमारी ट्रैकिंग प्रणाली यह सुनिश्चित करती है कि दस्तावेज चेकलिस्ट का एक हिस्सा है।

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

इंजीनियरिंग रिलीज बिना दस्तावेज के कर सकती थी। कुछ अनौपचारिक उपयोग नोट शुरू करने के लिए पर्याप्त अच्छे होने चाहिए।

Answer 6

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