2009-02-10 14 views
11

सवाल Documents for a project? के जवाब में, क्रिस बैलेंस ने उत्तर दिया कि "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.Agile दस्तावेज़ीकरण के विशिष्ट उदाहरण?

मेरा प्रश्न है, तो आप किसी भी अच्छा उदाहरण [एस] के बारे में पता है, जो मैं इंटरनेट पर (उदाहरण के लिए देख सकते हैं, या एक में किताब), इस तरह के दस्तावेज?

यदि संभव हो तो मैं कई उदाहरण देखने के लिए, सहित खुशी होगी:

  • लघु/लघु/सरल उदाहरण
  • बिग/लंबे/जटिल उदाहरण
  • प्रसिद्ध उदाहरण
  • उच्च गुणवत्ता उदाहरण

मुझे यह Google के लिए एक आसान विषय नहीं मिला: मुझे इसके बारे में बहुत कुछ पता चला है, लेकिन कम प्रदर्शन दिखा रहा है I टी।

उत्तर

6

किताबों के संबंध में शुरू करने के लिए एक बहुत अच्छी जगह User Stories Applied और Agile Estimation and Planning दोनों माइक कोह्न द्वारा है। इसमें पहले से ही चुस्त प्रक्रियाओं में आने वाले किसी के लिए उत्कृष्ट उदाहरण और अच्छे प्रारंभिक अंक हैं।

वेबसाइट संसाधनों तक वे कुछ और बहुत दूर हैं। संभवतः वास्तव में शुरू करने के लिए एक अच्छी जगह Google छवियों पर उन खोजशब्दों की खोज करेगी क्योंकि बहुत से लोग अपने बर्नडाउन चार्ट और उपयोगकर्ता कहानियों की तस्वीरें लेते हैं। इससे शुरू होने पर मुझे बहुत मदद मिली। यहाँ कुछ नमूने हैं: Burndown Chart, और User Stories

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

आशा है कि मदद करता है!

+0

मुझे यह जानकर हैरान है कि "वेबसाइट संसाधन कम और बहुत दूर हैं": इस प्रकार के दस्तावेज अभ्यास में उपयोग नहीं किए जाते हैं, फिर, "वर्चुअल टीम" (यानी भौगोलिक रूप से वितरित डेवलपर्स द्वारा) ओपन सोर्स (यानी सार्वजनिक रूप से उपलब्ध) परियोजनाएं? यदि नहीं, तो क्या आप अनुमान लगा सकते हैं कि क्यों नहीं? – ChrisW

+0

मैं वास्तव में एक दूरस्थ चुस्त टीम पर काम करता हूं और निश्चित रूप से हम रिमोट टूल्स का उपयोग करते हैं, मैंने सोचा था कि आप सीखने के एक पहलू से मतलब है। आभासी उपकरणों के लिए आपके पास Acunote, TargetProcess, Unfuddle जैसे विकल्प हैं। ये उपकरण दूरस्थ टीमों के लिए उपयोगी हैं लेकिन जब संभव हो तो कॉर्क बोर्ड को प्रतिस्थापित नहीं करना चाहिए। –

+0

तो मुझे लगता है कि आप कह रहे हैं कि उपयोगकर्ता कहानियां आदि * वर्चुअल टीमों द्वारा उपयोग की जाती हैं; लेकिन, वे वेब साइटों पर नहीं होते हैं, क्योंकि इसके बजाय वे वेब के अलावा टूल [जैसे आपने उद्धृत किए गए] का उपयोग करके लिखे गए हैं? – ChrisW

0

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

+0

केवल समझाते हुए कि क्यों यूएमएल का निर्माण नहीं करना मेरे प्रश्न का उत्तर नहीं होगा। – ChrisW

+0

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

1

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

विकास के दौरान उपयोगकर्ता दस्तावेज़ लिखने के बाद डिजाइन को मान्य करने में मदद करता है। तकनीकी लेखक भी आवेदन के डिजाइन में भाग लेते हैं।

यह रिलीज विस्फोट और स्प्रिंट बर्नडाउन के अतिरिक्त है।

अतिरिक्त दस्तावेज टीम द्वारा बनाया गया है जब उन्हें लगता है कि यह उत्पाद स्वामी के साथ संवाद करने में उपयोगी है। यह कम महत्वपूर्ण हो गया क्योंकि हम बेहतर उपयोगकर्ता कहानियां लिखना सीख रहे हैं।

+0

मैंने हमेशा सोचा है कि एक कार्यात्मक कल्पना सबसे उपयोगी दस्तावेज है। उपयोगकर्ता प्रलेखन कार्यात्मक विनिर्देश, आईएमओ का एक उप-वर्ग है। इसलिए, यदि आप कह रहे हैं कि उपयोगकर्ता दस्तावेज पर्याप्त है, और सॉफ्टवेयर के पहले और/या इसे विकसित करना अच्छा है, तो मुझे लगता है कि यह व्यवहार्य है। – ChrisW

+0

असल में, उपयोगकर्ता प्रलेखन डेवलपर्स के लिए पर्याप्त हो सकता है ("हम किस अंत उपयोगकर्ता कार्यक्षमता का निर्माण कर रहे हैं?") लेकिन प्रोजेक्ट मैनेजर्स ("इस स्प्रिंट * में क्या कर रहे हैं * और इसके विपरीत कम प्राथमिकता कार्यक्षमता के लिए क्या हो रहा है) कम से कम अगली बार परीक्षण किया जा रहा है और अनदेखा किया जा रहा है? ")। – ChrisW

3

मुझे लगता है कि इन दोनों सवालों के लिए, आप एलिस्टेयर कॉकबर्न की वेबसाइट पर स्कैन करने से बहुत खराब कर सकते हैं।

http://alistair.cockburn.us/Earned-value+and+burn+charts

(thoug मैं माइक कोहन के काम के पहले पोस्टर की सिफारिश गूंज): विशेष रूप से, वह burndown चार्ट और कुछ अलग अलग तरीकों से उन्हें उत्पन्न करने के लिए के बारे में जो शानदार लेख है।

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

यदि आप छोटी की दर्जन परिभाषाओं में से किसी एक "छोटी" परियोजना पर हैं, तो आप बहुत हल्की कहानियों के साथ ठीक हो सकते हैं। यहाँ कॉकबर्न की साइट से फिर से एक उदाहरण है,:

http://alistair.cockburn.us/Examples+of+ultra-light+use+cases

संबंधित मुद्दे