प्रोग्रामर विकी को बनाए रखना

Question

मुझे हाल ही में विकास टीम के लिए विकी का प्रभारी रखा गया था। विकी अभी भी अपने बचपन में है, इसलिए मेरे पास काम करने के लिए बहुत सी जगह है। इसका लक्ष्य विकास टीम के लिए आंतरिक घर बनाना है। वर्तमान में, विकी मानकों की जानकारी का मुख्य भाग कोडिंग मानकों है।

• आपकी देव टीम अपनी आंतरिक विकी के लिए उपयोग करने वाले कुछ सर्वोत्तम अभ्यास क्या हैं?
• देव विकी पर कौन सी जानकारी महत्वपूर्ण है?
• यदि आप अपनी देव टीम के लिए विकी में जाना चाहते हैं तो आप किस जानकारी को देखने की उम्मीद करेंगे?
• क्या ऐसी कोई जानकारी है जो विकी पर नहीं जाना चाहिए, भले ही यह एक अच्छा विचार जैसा प्रतीत होता है?

- संपादन -

• इसके अलावा, वहाँ जानकारी को व्यवस्थित करने के लिए एक अच्छा तरीका है?

Answer 1

• परिचय नई प्रोग्रामर के लिए स्रोत आधार
• जनरल प्रलेखन (नहीं प्रति-se API दस्तावेज़ है, लेकिन अधिक ट्यूटोरियल (जैसे परत दर (डेटा, यूआई), porject द्वारा, या अन्य रूप में) बातें) कर्मचारियों की
• सूचियां/जो कर रहा है की तरह क्या और कैसे उन तक पहुंचने के
• नोट्स/संसाधन/लेख है कि सॉफ्टवेयर में इस्तेमाल किया अवधारणाओं की व्याख्या
• निर्माण प्रक्रिया का प्रलेखन और codebase की फाइल सिस्टम लेआउट

अन्य चीजें मैं आमतौर पर डाल

• योजना/कार्य करने की सूचियों
• सूचना है कि दिलचस्प है दूसरों के लिए
• बाकी सब कुछ है कि मुझे लगता है कि साझा किया जाना चाहिए

Answer 2

पढ़ने के लिए देखते हैं

• बुरडाउन चार्ट
• कॉम (के लिए जब नए लोग शुरू अच्छा) विकास के वातावरण के लिए सोमवार सेटअप जानकारी
• चश्मा
• ज्ञात मुद्दे और विकास उपकरण के साथ समाधान

Answer 3

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

कोडिंग मानकों के अलावा, हम अपने कोड बेस, नए कर्मचारियों के लिए सेटअप जानकारी और सामान्य पर्यावरण जानकारी के साथ काम करने के लिए सुझाव और युक्तियां रखते हैं।

Answer 4

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

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

घर पुस्तकालयों में उदाहरण अच्छे हैं। और/या "स्टोरीबोर्ड" एक विधि के माध्यम से उपयोगकर्ता को चल रहा है जब MethodX कहा जाता है।

Answer 5

आपकी देव टीम अपनी आंतरिक विकी के लिए उपयोग करने वाले कुछ सर्वोत्तम अभ्यास क्या हैं?

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

देव विकी पर कौन सी जानकारी महत्वपूर्ण है?

• एक परियोजना, मील के पत्थर, वितरण तिथियों आदि डिजाइन फैसले/बैठकों के
• सारांश बारे में सामान्य जानकारी। महत्वपूर्ण है कि आप बार-बार उसी क्षेत्र में फिर से न आएं।
• HowTo गाइड मौजूदा परियोजनाओं के सामान्य विकास के लिए (उदाहरण के लिए, कैसे एक नई प्लग इन विकसित करने के लिए)

आप अपने देव टीम के लिए विकी आपको कौन सी जानकारी देखने की अपेक्षा करेंगे पर जाने के लिए थे, तो?

परियोजना जानकारी, जो कि आदि पर काम कर रही है, डिजाइन निर्णय। उपयोगी साइटों के लिए सर्वोत्तम प्रथाओं और लिंक भी।

क्या ऐसी कोई जानकारी है जो विकी पर नहीं जाना चाहिए, भले ही यह एक अच्छा विचार जैसा प्रतीत होता है?

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

Answer 6

हमारे पास विकास विकी थी और यह एक अच्छा उपकरण था। हमने इसे सब कुछ के लिए उपयोग किया!

• जब नए विचारों को समझते हैं, तो हम उन्हें विकी पर ले जाएंगे। विकी की कम घर्षण प्रकृति ने संगठन में किसी के लिए यह आसान बना दिया (हम एक छोटे स्टार्टअप थे) जैसे विचारों को जोड़ने के लिए। हमारे पास एक उच्च स्तर "brainstorming" पृष्ठ था जो विस्तृत विचारों से जुड़ा हुआ था जिसमें प्रत्येक विचार का पूर्ण विवरण था।
• प्रत्येक पुनरावृत्ति के लिए, हम उस विचार के लिए फीचर सूची में "brainstorming" सूची से फीचर विचार आइटम "स्थानांतरित" करेंगे। डिज़ाइन और कार्यान्वयन विवरण शामिल करने के लिए सुविधा का ब्योरा बाहर निकाला गया था।
• जैसी विशेषताएं पूरी होने के बाद, पुनरावृत्ति पृष्ठ हमारे रिलीज नोट्स पेज बन गया - जिसमें हमारे संस्करण नियंत्रण प्रणाली से रिलीज टैग भी शामिल था।
• हमारे पास एक बग पेज था जो फीचर पृष्ठों के समान काम करता था। बग फिक्स को पुनरावृत्ति/रिलीज़ पृष्ठों में जोड़ा गया था क्योंकि वे काम/पूर्ण थे।
• हमने विकी पर हमारे उपयोगकर्ता दस्तावेज़ भी बनाए और रिलीज के साथ उन पृष्ठों को निर्यात किया।

जैसे ही समय चल रहा था। इस उपकरण को अधिक से अधिक मूल्यवान देखा गया था। हम जिस कंपनी पर काम कर रहे थे, उनके लिए विभिन्न विकी बनाने के लिए हम घायल हो गए।

मुझे आशा है कि आपको अपना विकास विकी उतना ही उपयोगी लगेगा जितना हमने किया था!

Answer 7

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

उदाहरण के लिए, "वर्तमान बर्डडाउन चार्ट" पृष्ठ होने के बजाय, "10-27-2008 के सप्ताह के लिए बर्नडाउन चार्ट" के लिए एक पृष्ठ बनाएं और फिर लोगों को चार्ट पर टिप्पणी करने के लिए प्रोत्साहित करें, और इसका क्या अर्थ है, और आपने उस सप्ताह इतनी खराब क्यों की।

Answer 8

सबसे कठिन हिस्सा डेवलपर्स को आपके विकी का उपयोग करने के लिए मिल रहा है। http://possibility.com/wiki/index.php?title=GettingYourWikiAdopted

प्रक्रियाओं

हो रही एक विकी अपनाया कठिन है एक चैंपियन

आपत्तियों

निकालें बनाएं सामग्री

विकी जाल में फंसना कंपनी में है

: मैं यहाँ कुछ लंबे समय से सुझाव है

का प्रचार करें बातचीत

बस यह करो के लिए विकी का उपयोग नहीं करने पर विचार करें

गिव अप मत करो! एक बजट

प्रतीक्षा न करें एक संक्रमण योजना

आपका विकी को बढ़ावा देना

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

Answer 9

विकीस सॉफ्टवेयर विकास टीमों के लिए एक मूल्यवान संसाधन हो सकता है लेकिन वे चांदी की बुलेट नहीं हैं। विकी बनाने के लिए यह बहुत आसान है जो तेजी से दुरुपयोग में पड़ता है या पुराना हो जाता है।

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

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

यदि आप प्रबंधक नहीं हैं, तो आपको बोर्ड पर प्रबंधक प्राप्त करने की आवश्यकता है क्योंकि इसे कुछ "प्रवर्तन" की आवश्यकता होगी।

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

Answer 10

हम घर और इनहाउस टीम विकी। और वहाँ हम सभी आवश्यक जानकारी प्रत्येक परियोजना के हम विकसित कर रहे हैं के लिए डाल दिया:

• खजाने
• पतों आभासी मशीनों के लिए
• पासवर्ड
• परियोजना दस्तावेजों
• परियोजना सिंहावलोकन
• परियोजना स्थिति

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

Answer 11

Wikipatterns एक वेबसाइट है जो सर्वोत्तम विकी प्रथाओं को दस्तावेज करने के लिए समर्पित है। वे एंटी-पैटर्न का भी वर्णन करते हैं और उनसे निपटने के तरीकों के बारे में बात करते हैं। मैंने अपनी पुस्तक पढ़ी और 150+ व्यक्ति संगठन में जमीन से विकी प्राप्त करने के लिए यह एक बड़ी संपत्ति थी।