चंचल प्रक्रिया: कैसे और क्या प्रलेखित किया जाना चाहिए?

Question

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

उन्होंने परियोजना के पूरा होने पर छोड़ दिया, लेकिन परियोजना टीम में से एक के साथ। वार्षिक सदस्यता के कारण परियोजना विकी साइट को अब बंद कर दिया गया है।

जब वे चले गए तो उन्होंने अपने साथ विकसित किए गए अधिकांश ज्ञान और समझ को ले लिया।

इसलिए मेरे 2 मुख्य प्रश्न हैं;

1. क्या यह चुस्त के लिए सामान्य है या सिर्फ एक बहाना है जो इसे लिखना नहीं चाहता है?
2. विकास की आवश्यकताओं, डिजाइनों, प्रमुख निर्णयों और संदर्भ को रिकॉर्ड करने के लिए फुर्तीली परियोजनाओं में प्रलेखन के लिए उद्योग के मानक क्या हैं?

Comments

en.wikipedia.org/wiki/There%27s_a_sucker_born_every_minute गंभीरता से - क्या आपने for.eikipedia.org/wiki/Bus_factor को नहीं देखा ? ठीक है, एक सबक सीखा है कि वह कठिन तरीके से अच्छी तरह से सीखा जाता है। उम्मीद है, आपके लिए, अगली बार नहीं होगा (लेकिन आप अभी भी व्यवसाय में

— रहेंगे

Answer 1

क्या यह चुस्त के लिए सामान्य है या सिर्फ एक बहाना है जो इसे लिखना नहीं चाहता है?

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

इसका मतलब यह है कि चुस्त काम नहीं करता है? बेशक, इसका मतलब यह नहीं है कि चुस्त आपको कुछ सामान्य समस्याओं को हल करने में मदद करता है, लेकिन आप अभी भी अन्य सभी के प्रभारी हैं। और कई मामलों में चुस्त सिर्फ उस कंपनी में उस टीम के लिए उपयुक्त नहीं है।

विकास की आवश्यकताओं, डिजाइनों, प्रमुख निर्णयों और संदर्भ को रिकॉर्ड करने के लिए फुर्तीली परियोजनाओं में प्रलेखन के लिए उद्योग के मानक क्या हैं?

छोटा होना:

टीम को परिभाषित करना चाहिए कि उन्हें कितने प्रलेखन की आवश्यकता है

वे डोमेन को जानते हैं, वे विशेषज्ञ हैं और इससे भी महत्वपूर्ण बात वे निर्माण करते हैं!

एजाइल मेनिफेस्टो में व्यापक प्रलेखन पर काम करने वाले सॉफ्टवेयर का यही मतलब है।

Answer 2

क्या उन्होंने आपको TDD टेस्ट, स्वीकृति टेस्ट या अन्य यूनिट टेस्ट का एक सेट छोड़ दिया है? वे यह प्रमाणित करने का एक अच्छा काम करते हैं कि एक आवेदन कैसे काम करता है और काम करने की अपेक्षा की जाती है, साथ ही जो विकसित किया गया था उसका उपयोग करने का एक नमूना कार्यान्वयन प्रदान करने के लिए भी।

Comments

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

— मार्टिन विकमैन

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

— ग्राम्पमीकी

Answer 3

जब तक मैं किसी भी तरह से एक चुस्त विशेषज्ञ नहीं हूँ, यहाँ एक उत्तर में मेरा प्रयास है:

1. क्या विशिष्ट दस्तावेज के लिए कहानी / आवश्यकता थी? यदि नहीं, तो यह समस्या का हिस्सा है क्योंकि आपको कुछ हद तक अनुरोध किया जाता है। यह एक बहाना है और मुझे आश्चर्य हो सकता है कि आपके यहाँ "सामान्य" से क्या मतलब है। क्या यह फुर्तीले सिद्धांतों का पालन करने वालों का बहुमत है जो कुछ सामान्य करता है या यह समग्र प्रक्रिया का हिस्सा है जिसकी उम्मीद की जानी चाहिए? वे दो दृश्य हैं जिन्हें मैं इसके लिए देख सकता था। संपादित करें: मुझे संदेह है कि कुछ भी ऐसा है जो टीमों के बहुमत है वही है जब यह प्रलेखन की बात आती है, लेकिन यह मेरी ओर से एक अनुमान है।

2. एक जोड़ी लिंक जो ब्याज की हो सकती है, इस बारे में सबसे अच्छा मैं कर सकता हूं:

   • एजाइल / लीन डॉक्यूमेंटेशन के लिए सर्वश्रेष्ठ अभ्यास
   • फुर्तीली और तकनीकी दस्तावेज

एजाइल के घोषणापत्र में कुछ विशिष्ट बिंदु हैं , जहां मैं नोट के साथ इसे इंगित करूंगा:

व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर

यही है, जबकि दाईं ओर की वस्तुओं में मूल्य है, हम बाईं ओर की वस्तुओं को अधिक महत्व देते हैं।

Comments

@JB सामान्य शब्द का उपयोग यह पता लगाने के लिए किया गया था कि अधिकांश टीमें क्या करती हैं।

— ग्राम्पमीकी

Answer 4

वे सिर्फ भयानक हैं। मेरा मानना ​​है कि चुस्त का मतलब कोई दस्तावेज नहीं है। उनके पास कम से कम आवेदन विवरण का ट्रैक होना चाहिए। उनकी विकि का निर्यात प्राप्त करना अच्छा होता या किसी और को सेवा शुल्क लेने की अनुमति होती।

यह कुछ प्रयास के रूप में विस्तृत नहीं हो सकता है। सिद्धांत है, जब एक समय-क्रंच में, चश्मा अब किसी भी तरह कोड से मेल नहीं खाता है। तो आपके पास कोड लिखने के लिए पर्याप्त दस्तावेज हैं और इसे विस्तार से परिभाषित करने की कोशिश नहीं करते हैं (कुछ छद्म-मौखिक / पाठ-आरेख-कोड में कोड लिखने की तरह और फिर वास्तविक कोड में।)।

Answer 5

आपकी समस्या का एजाइल से कोई लेना-देना नहीं है। उन्हें आपके द्वारा मांगे गए दस्तावेज़ का उत्पादन करना चाहिए था। परियोजना को खराब तरीके से प्रबंधित किया गया था।

Answer 6

कम से कम, कहीं न कहीं सुविधाओं, उपयोगकर्ता कहानियों और परीक्षण मामलों का कुछ विवरण होना चाहिए । आईटी परियोजनाओं में रीडमी फाइलों में हो सकता है, यह स्रोत-कोड टिप्पणियों में हो सकता है, यह डिजाइन दस्तावेजों में हो सकता है; यह उपरोक्त सभी हो सकता है ... या यह MIA ​​हो सकता है!

Answer 7

मेरे अनुभव में हमेशा बहुत सारे लोग दस्तावेज़ीकरण की मांग करते हैं (मैं उनमें से एक रहा हूं) लेकिन व्यवहार में किसी के पास वास्तव में समय या उन्हें बनाने की इच्छा नहीं है। कभी-कभी प्रयास होते हैं, लेकिन आमतौर पर बनाए गए दस्तावेज़ बहुत जल्दी पुराने हो जाते हैं और सिस्टम के वास्तविक कामकाज के साथ सिंक से बाहर हो जाते हैं। यह एक ऐसी स्थिति की ओर ले जाता है, जहां आपके पास दस्तावेज़ीकरण होने के बावजूद, वास्तव में इसकी जाँच करने से परेशान होते हैं, क्योंकि वे केवल सटीकता पर भरोसा नहीं करते हैं।

वास्तविक सटीकता और विश्वसनीय जानकारी के लिए यह बहुत कोड और परीक्षण पढ़ने में सक्षम होने के लिए नीचे आता है। (पुनः) चाहने वाले ग्राहक को पता चलता है कि उसका सिस्टम हमेशा एक प्रोग्रामर का साक्षात्कार और क्वेरी कर सकता है जो सिस्टम के बारे में तथ्यों (कुछ जांच के साथ) प्रस्तुत कर सकता है।

अच्छा दस्तावेज़ीकरण बनाना -not- तुच्छ है और काफी महंगा हो सकता है। दूसरी बात यह है कि दर्शकों के बारे में कोई भी आश्चर्यचकित हो सकता है कि यह दस्तावेज किसके लिए है और इसे प्रदान करने का इरादा क्या है?

Comments

लगता है कि आप इस तथ्य के बाद प्रलेखन का उल्लेख कर रहे हैं (कृपया मुझे माफ कर दें यदि मैं गलत हूं)। तथ्य से पहले प्रलेखन के लिए जो कुछ भी हुआ? ओ

— टेम्परा