बिना स्वीकृति मापदंड के आप सॉफ्टवेयर कैसे विकसित करते हैं?

Question

आप बिना किसी कसौटी के 4-5 डेवलपर्स की टीम में सहयोगात्मक रूप से सॉफ्टवेयर कैसे विकसित करते हैं, बिना यह जाने कि टेस्टर प्रोडक्ट के मालिक के रूप में काम करने वाले मल्टीपल (2-3) लोगों के साथ क्या करेंगे।

हमारे पास कुछ स्क्रीन शॉट्स और कुछ बुलेट पॉइंट्स के साथ एक स्केच 'कल्पना' है।

हमें बताया गया है कि यह आसान होगा इसलिए इन चीजों की आवश्यकता नहीं है।

मैं आगे बढ़ने के नुकसान पर हूं।

अतिरिक्त जानकारी

हमें एक कठिन समय सीमा दी गई है।

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

उत्पाद के स्वामी प्रश्नों का उत्तर देने या प्रतिक्रिया देने के लिए आसानी से उपलब्ध नहीं हैं। कोई नियमित रूप से निर्धारित बैठकें या उनके साथ कॉल नहीं हैं और प्रतिक्रिया में दिन लग सकते हैं।

मैं समझ सकता हूं कि हमारे पास एक आदर्श युक्ति नहीं हो सकती है, लेकिन मुझे लगा कि जिन चीजों पर हम वास्तव में काम कर रहे हैं, उनके लिए स्वीकृति मानदंड रखना 'सामान्य' होगा।

Comments

मैं कहूंगा, इसे विकसित करें लेकिन आप चाहते हैं। जब तक आप एक बैठक में जाकर सहज महसूस करते हैं और यह प्रदर्शित करते हैं कि आपका उत्पाद स्केच "कल्पना" और स्क्रीनशॉट से कैसे मेल खाता है, मुझे लगता है कि आप ठीक हैं। बेशक, आप हमेशा आगे के विवरण के लिए कल्पना के निर्माता से पूछ सकते हैं ...

— FrustratedWithFormsDesigner

मूल रूप से यह स्वचालित विकास या "काउबॉय कोडिंग" है। डेवलपर्स विवरण में भरते हैं। डेवलपर्स के पास बहुमत नियंत्रण है। मूल रूप से आपके पास कभी औपचारिक आवश्यकताएं नहीं होंगी। विकसित, स्टैकहोल्डर (ओं) के लिए डेमो, प्रतिक्रिया इकट्ठा, कुल्ला और दोहराएं।

— जॉन रेनोर

क्या उत्पाद स्वामी यह समझता है कि लागत और समय सर्पिल को उच्च और उच्चतर सुनिश्चित करने का यह एक उत्कृष्ट तरीका है? गैर-कंप्यूटर वैज्ञानिक, अक्सर अच्छी तरह से लिखे गए स्पष्ट विनिर्देशों के महत्व को नहीं समझते हैं। उदाहरण के लिए, अमेरिकी सरकार अक्सर ऐसे ही मुद्दों पर चलती है, जब वे नए सैन्य हार्डवेयर के लिए उम्मीदें बदलते हैं। यह कई कारणों में से एक है कि क्यों सैन्य हार्डवेयर अक्सर अति व्यस्त हो जाता है और अनुसूची के पीछे होता है। joelonsoftware.com/2000/10/02/…

— निकल्ह

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

— jpmc26

आपको विफलता के लिए सेट किया गया है। यह उस तरह की चीज है जिसे प्रबंधन को आगे बढ़ाने की जरूरत है। यदि आपके पास कठिन समय सीमा नहीं थी, तो आप सफल होने तक पुनरावृति कर सकते थे। यदि हितधारक प्रतिक्रिया के लिए उपलब्ध थे, तो आप तेजी से (संभवतः) समय सीमा को पूरा कर सकते हैं। वास्तव में काफी विस्तृत कल्पना के लिए डिट्टो। लेकिन कुछ देना पड़ता है । यह वह हिस्सा है जहां आप अपने बॉस से बहुत अच्छी तरह से अपने @ $ $ को आग से बाहर निकालने के लिए कहते हैं।

— जारेड स्मिथ

Answer 1

विस्तृत विवरण के बिना, एक पुनरावृत्त प्रक्रिया इसे अच्छी तरह से प्राप्त करेगी।

बस एक स्केचिंग प्रोटोटाइप बनाएं, ग्राहक से प्रतिक्रिया के लिए पूछें, प्रतिक्रिया के आधार पर परिवर्तन करें, और इस प्रक्रिया को तब तक दोहराएं जब तक कि आवेदन पूरा न हो जाए।

क्या ग्राहक इसे करने के लिए पर्याप्त रोगी है या नहीं यह एक अलग सवाल है। कुछ ग्राहक और डेवलपर वास्तव में इस प्रक्रिया को पसंद करते हैं; चूंकि ग्राहक हमेशा हाथों में रहता है, वह (अंततः) वही प्राप्त करेगा जो वह चाहता है।

यह कहे बिना जाना चाहिए कि आप इस तरह एक निश्चित लागत या निश्चित समय अनुबंध पर काम नहीं करने जा रहे हैं।

Comments

एक को जोड़ना चाहिए: "बस सुनिश्चित करें कि आपको प्रति घंटे भुगतान किया जाता है", और न केवल "भुगतान किया जाता है जब ग्राहक विचारों से बाहर चल रहा है जो गायब है"।

— डॉक ब्राउन

यह भी सुनिश्चित करें कि ग्राहक क्या सोचता है, उसे भी दस्तावेज करना सुनिश्चित करें, इसलिए यह कम से कम कहीं न कहीं नोटों में कैद है। यह औपचारिक स्वीकृति मानदंड नहीं हो सकता है, लेकिन जब आप वास्तव में अगले कदम करने की कोशिश कर रहे हैं, तो यह बहुत प्रासंगिक है ..

— एंडरलैंड

@ डॉक ब्राउन: ओपी को "ग्राहक आंतरिक है" को जोड़ने के लिए संपादित किया गया है - इसलिए घंटे के हिसाब से भुगतान एक मुद्दा नहीं है।

— सालेस्के

+1 ने कई आंतरिक परियोजनाओं के लिए इस प्रक्रिया का पालन किया और पाया कि यह वास्तव में अच्छी तरह से काम करती है और इसके अलावा, एक समग्र समय सेवर है। एक टिप पुनरावृत्तियों को कम रखने के लिए है: एक या दो सप्ताह।

— बॉब Tway

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

— स्टीव जेसप

Answer 2

यदि आप जो कह रहे हैं वह सच है और कल्पना कहीं भी आपके पास शुरू करने के लिए पर्याप्त नहीं है (और आप इस मूल्यांकन में ईमानदार हो रहे हैं), तो मैं यह सलाह देता हूं:

1. स्केच और "स्केच" कल्पना पढ़ें जिसे आपको दिया गया है।
2. अपने स्वयं के स्तर को लिखें जो आपके लिए कोड करने में सक्षम होने के लिए पर्याप्त है । आपको एक टन का अनुमान लगाना पड़ सकता है।
3. समीक्षा के लिए ग्राहक को अपनी कल्पना दिखाएं। उन हिस्सों पर ध्यान दें, जो उन्हें पसंद हैं, और उन हिस्सों पर अधिक जानकारी प्राप्त करें जहां उन्हें लगता है कि आपने इसे गलत कर लिया है।
4. चरण 2 और 3 को तब तक दोहराएं जब तक कि आप और ग्राहक सिंक में न हों।
5. अब आपके पास एक पर्याप्त कल्पना है।

यदि आपका ग्राहक सही था जब उन्होंने कहा "यह आसान होगा," तो यह व्यायाम केक का एक टुकड़ा होना चाहिए।

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

Comments

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

— स्टीव जेसप

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

— करण

your draft specification will quickly illustrate the problem and communicate to them that they were wrong (....) since it will be right in front of them and obvious- मैं उस ग्राहक को इंगित करना चाहता हूं जो महसूस करते हैं कि यह सब बिल्कुल स्पष्ट है कि वे ग्राहक हैं जिनके साथ शुरू करने के लिए आपके पास कभी भी यह समस्या नहीं होगी। या, इसे और अधिक संक्षेप में कहें: समाधान का अर्थ है गैर-अस्तित्व की समस्या (जो कि एक विरोधाभास है जिसे मैं जीवन के सभी क्षेत्रों में अधिक से अधिक बार पहचानता हूं) ...

— रादू मुरझिया

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

— जॉन वू

Answer 3

उत्पाद के मालिक ने आपको एक प्रोटोटाइप सौंप दिया; उसे वापस बेहतर लोगों को सौंप दें (जब तक आप कर रहे हैं)

ऐसा लगता है कि आपको प्रोजेक्ट शुरू करने के लिए एक पेपर प्रोटोटाइप प्रदान किया गया है। यह एक भयानक शुरुआत नहीं है। मेरा सुझाव है कि आप उत्तरोत्तर सक्षम प्रोटोटाइप प्रदान करके, उसी भाषा में व्यवसाय के स्वामी से संवाद करें ।

आपके प्रोटोटाइप को कागज से शुरू होना चाहिए, डिजिटल मॉकअप पर चलना चाहिए, और फिर "वास्तविक" प्रौद्योगिकियों के साथ निर्मित होना चाहिए।

ट्रीहाउस के पास इसके लिए एक उत्कृष्ट मार्गदर्शक है, जो निष्कर्ष निकालता है:

एक रूपरेखा के साथ प्रोटोटाइप के बारे में आश्चर्यजनक बात यह है कि प्रोटोटाइप अक्सर वास्तविक साइट बन जाता है क्योंकि संरचना और स्टाइल पहले से ही जगह में हैं। अगर यह उसी ढांचे का उपयोग करने जा रहा है तो साइट को खरोंच से दोबारा बनाने की कोई आवश्यकता नहीं है।

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

अपनी समय सीमा पूरी करें

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

आपकी समय-सीमा सबसे अच्छी परिभाषित परिभाषा है। पूर्ण और सुसंगत कुछ है जो आप समय पर वितरित कर सकते हैं।

अपने परीक्षकों के साथ सहयोग करें

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

पता करें कि क्या परीक्षकों के पास कुछ भी है, जो उन्हें प्रदान करने की आवश्यकता है, जैसे प्रमाण-परीक्षण के दस्तावेज, जिसे आप "वापस" कर सकते हैं।

टेस्ट फर्स्ट डिजाइन ट्राई करें

चूंकि आपके पास कोई औपचारिक आवश्यकता नहीं है, इसलिए परीक्षण मामलों को विकसित करने के लिए कुछ संरचना प्रदान करना होगा।

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

मानकों के लिए छड़ी, विशेष रूप से यूआई के लिए

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

अपनी साइट के लिए एक मानक UI चुनें और इसे निर्देशित न करें / जब तक कि इसका निर्देशन न किया जाए। मुझे नहीं पता कि आप किस प्लेटफ़ॉर्म के लिए विकसित कर रहे हैं, लेकिन बूटस्ट्रैप या Google सामग्री डिज़ाइन दो उदाहरण हैं।

संवाद करें, लेकिन विराम न दें

मैं एक दिन उत्पाद के मालिक को एक ईमेल भेजने का सुझाव दूंगा। यदि आपातकाल है तो केवल इससे अधिक भेजें।

यदि आपके पास प्रश्न हैं, तो वर्णन करें कि मार्गदर्शन प्राप्त नहीं होने पर आप कैसे आगे बढ़ेंगे। उदाहरण के लिए:

क्या इस ऐप के उपयोगकर्ताओं को मोबाइल उपकरणों के साथ इसे एक्सेस करने की आवश्यकता होगी? अभी हम मान रहे हैं कि यह केवल एक डेस्कटॉप / लैपटॉप होगा।

घबराओ मत

मैं उन लोगों के लिए बहुत सारी परियोजनाएं शामिल कर रहा हूं जिन्हें "आवश्यकता" शब्द की जानकारी नहीं थी। अधिकांश सफल थे। हैंड्स-ऑफ उत्पाद के मालिक आपको महान समाधान बनाने के लिए अक्षांश देते हैं।

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

Comments

एक बिंदु जिसका उल्लेख नहीं किया गया है वह है हार्ड डेडलाइन: यह महत्वपूर्ण होगा कि उस तारीख को कुछ दिया जाए, और यह कार्य (गतियों के माध्यम से) हो जाए, भले ही घंटियाँ, सीटी और तेज़ धारियाँ गायब हों। जगह में उस सीमा के साथ, @Tim बनाता है कि अन्य सभी बिंदुओं ठीक जाना चाहिए

— फिलिप

@PhilipOakley, प्रतिक्रिया के लिए धन्यवाद। मैंने पुनरावृत्त प्रोटोटाइप प्रक्रिया के बारे में एक बिंदु जोड़ा कि एक चूक समय सीमा को रोकने के लिए तेजी से स्वीकार्य "डिलिवरेबल्स" का उत्पादन करना चाहिए। यदि इससे सहायता मिलती है तो मुझे बताएं।

— टिम ग्रांट

यह एक सुधार है। हो सकता है कि 'मीटिंग' को 'मीट' में बदलना भी अनिवार्य हो। फिर शायद यह कथन भी जोड़ दें कि यदि उन्होंने अन्य सामान के बिना कोई तारीख दी है, तो वह महत्वपूर्ण आवश्यकता बन जाती है, ताकि निम्नलिखित 'नोट' में संदर्भ हो। (अक्सर ग्राहक केवल समय और लागत के बारे में चिंतित होते हैं, बाकी सौंदर्य प्रसाधन और फैशन है, जैसा कि मुझे यकीन है कि आप जानते हैं ;-)

— फिलिप ओकले

Answer 4

एक परियोजना अनिश्चितता को कम करने का कार्य है जब तक निश्चितता हासिल नहीं हो जाती :

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

यह प्रगतिशील विस्तार का सिद्धांत है: आवश्यकताओं, मानदंड और परिणाम कदम-दर-चरण विस्तृत होंगे, जैसा कि विकास प्रक्रिया में उनकी भागीदारी के माध्यम से ग्राहक की अपनी अपेक्षाओं और आवश्यकताओं की समझ होगी।

क्या ये एक दिक्कत है ?

स्केचियर प्रारंभिक आवश्यकताओं, उच्च अनिश्चितता, और कार्यों को करने के लिए आवश्यक समय जितना अधिक होगा। तो यह सिर्फ एक बात है कि अतिरिक्त काम कौन करेगा और लागत का भुगतान कौन करेगा।

इन दोनों सवालों का जवाब अनुबंध में होना चाहिए। या एक वार्ता का विषय होगा। और ग्राहक को अतिरिक्त भागीदारी को स्वीकार करना होगा (मुख्य तर्क "कचरा में, कचरा बाहर होगा" होगा, हालांकि मैं आपको इसे अधिक राजनयिक तरीके से पेश करने की सलाह दूंगा;;)

Comments

मुझे पहला वाक्य बहुत पसंद है। इसके लिए बहीखाता यह है कि ग्राहक हो सकता है: 1) कुछ निश्चित नहीं है कि वे क्या चाहते हैं, 2) अपने दिमाग को बदल दें क्योंकि वे जाते हैं, 3) कुछ अस्वीकार्य चाहते हैं। लेकिन अगर यह वास्तव में एक सरल परियोजना है, तो इसके सफल होने का एक अच्छा मौका है।

यह एक सोना है।

— ब्रूनो गार्डिया

Answer 5

" कोई नियमित रूप से निर्धारित बैठकें नहीं हैं "। ठीक है, फिर आप नियमित बैठकों को निर्धारित करके क्यों नहीं शुरू करते हैं ? तथ्य यह है कि आपके पास कई उत्पाद स्वामी गारंटी देते हैं कि आपकी परियोजना आसान नहीं होगी, क्योंकि उन लोगों में से प्रत्येक के पास परस्पर विरोधी आवश्यकताएं होंगी, जो मौजूद सभी हितधारकों के साथ चर्चा की जानी चाहिए।

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

Answer 6

स्पष्ट आवश्यकताओं के बिना एक परियोजना, ढीला नेतृत्व, की कोई परिभाषा नहीं (DoD), कोई भी यह सुनिश्चित करने के लिए जवाबदेह होने को तैयार नहीं है कि आपके पास जानकारी है जिसे आपको अपने काम को समय पर करने की ज़रूरत है और उनकी समय सीमा को पूरा करने के लिए परियोजना के लिए एक नुस्खा है विफलता।

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

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

किसी पर विश्वास न करें जब वे आपको बताएंगे तो यह आसान होगा । कभी-कभी यह वास्तव में जितना आसान लगता है उतना ही सरल होता है, और मुझे इस पर विश्वास हो सकता है अगर (और केवल अगर ) तो मैं उत्पाद मालिकों को अच्छी तरह से जानता हूं कि वे पूरी तरह से भरोसा करते हैं कि आवश्यकताओं को वास्तव में जितना वे कहते हैं, उतना सरल है और मेरे पास है बशर्ते स्व-व्याख्यात्मक हो (यदि नहीं, तो मैं एक प्रश्नोत्तर सत्र और यह दस्तावेज करता हूं)। मैं बहुत सी स्थितियों में रहा हूँ जहाँ एक ऑपरेशन के दृष्टिकोण से आसान अविश्वसनीय रूप से कठिन हैएक विकास के दृष्टिकोण से, या आपको लगता है कि आप पूरी तरह से हो चुके हैं और आप निराशा के शब्दों को सुनते हैं ("ओह, वैसे, हम भूल गए ...")। उदाहरण ... "आपको बस इतना करना है कि इन पीडीएफ फाइलों को एक डॉक्यूमेंट रिपॉजिटरी से बाहर पढ़ना है,", जो स्वीकृति परीक्षण के दौरान बदल जाता है, "ओह, हम भूल गए कि इनमें से कुछ को पूरी तरह से असंगत तरीके से बग़ल में पढ़ा गया था, और कुछ में गलत पृष्ठ आकार परिभाषित है, और कुछ को इन तीन पृष्ठों की आवश्यकता है, और हमें उन सभी को समान प्रदर्शित करने की आवश्यकता है। यह ठीक करना आसान है, ठीक है? "।

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

Answer 7

एक कल्पना के बिना, आपके पास टीम वर्क है। चपल हो जाओ।

पीओ के साथ बैठो और एक छोटी सी कहानी / ies शुरू करो। "हम सिर्फ इस स्क्रीन को देने जा रहे हैं, सिर्फ इस बटन के साथ जो 'बिंग!" जाता है। कुछ AC पर बसा। कहानी सुनाते हैं। कहानी का प्रदर्शन । बटन लाल होने चाहिए। एक बग या एक नई कहानी उठाएँ। उन बटनों को वितरित करें जो बोंग और बैंग जाते हैं। और इसी तरह।

सहयोगात्मक रूप से छोटे ऊर्ध्वाधर स्लाइस को निर्दिष्ट और वितरित करना जो अक्सर प्रदर्शित होते हैं।

यदि ग्राहक इस तरह से आपके साथ काम नहीं करेगा, तो बाहर का रास्ता खोजें।

Answer 8

मैंने कई प्रोजेक्ट्स कर रहे हैं, जैसे आपने उल्लिखित किए हैं। जब तक पीओ जानता है कि आप क्या डिजाइन निर्णय ले रहे हैं और आपको उन्हें क्यों बनाना है, तो आपको ठीक होना चाहिए। यदि, दूसरी ओर, वे डिजाइन निर्णयों को नहीं समझते हैं, तो आपको कम से कम एक लिखित उपयोगकर्ता स्वीकृति परीक्षण दस्तावेज़ के लिए उन्हें दबाने की आवश्यकता है।

Answer 9

कोड लिखना शुरू करने से पहले आपको एक विस्तृत, सत्यापन योग्य युक्ति की आवश्यकता होती है। यह एक तथ्य है, और इसके आसपास कोई नहीं है।

अगर कोई और उस कल्पना को लिखने के लिए तैयार नहीं है, तो डेवलपर्स को इसे लिखना होगा। तो आपको एक अधूरा चश्मा मिलता है। आप इसे एक पूर्ण युक्ति में बदल देते हैं (जिसका अर्थ है "यह वही है जिसे मैं लागू करने जा रहा हूं जब तक कि कोई और मुझे नहीं बताता")। आप उस हिस्से को हितधारकों को सौंपते हैं और उन्हें कल्पना को संशोधित करने का मौका देते हैं। केवल कल्पना को संशोधित करने का एक मौका - उदाहरण के लिए इसे अनिर्दिष्ट न करके "मुझे यह पसंद नहीं है"। उस बिंदु पर, यह आपकी कल्पना है, या वे एक अलग कल्पना की आपूर्ति कर सकते हैं, लेकिन कल्पना को हटा नहीं सकते।

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

Comments

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

— whatsisname

@whatsisname सहमत मैंने भी इस तरह से कोड लिखा है। यह तब होता है जब कार्य का एक खोजपूर्ण पहलू होता है। अब एक युक्ति के बिना कोडिंग में कमियां हैं, लेकिन कभी-कभी वे यह कहकर अधिक स्वीकार्य होते हैं कि आप एक लक्ष्य को पूरा नहीं कर सकते।

— Cort Ammon

@whatsisname, phrasing में सुधार किया जा सकता है, लेकिन मूल सत्य यह है कि आप यह समझे बिना किसी अनुरोध को पूरा नहीं कर सकते कि यह क्या है। अगर मैं सिर्फ कहता हूं, "मुझे जावा में एक प्रोग्राम लिखें," तो आपके लिए उस प्रोग्राम को लिखना असंभव है । आप अपना खुद का विचार बना सकते हैं कि कार्यक्रम को क्या करना चाहिए - दूसरे शब्दों में, अपने लक्ष्य का आविष्कार करें, और फिर उसे पूरा करें- लेकिन यह एक लक्ष्य प्राप्त करने के लिए एक शुद्ध असंभव है जिसे आपके सहित कभी भी किसी ने भी नहीं कहा है। यह किसी भी अनुरोध पर लागू होता है , बड़ा या छोटा; इससे पहले कि आप कर सकें, उत्पादन और / या प्रस्तुत कर सकें , जरूरतों और चाहतों को समझा जाना चाहिए ।

— वाइल्डकार्ड

उस ने कहा ... विस्तार का स्तर जिसे समझने के लिए वास्तव में एक अनुरोध की आवश्यकता होती है और जिसे पूरा किया जा सकता है, उसे अत्यधिक कम करके आंका जा सकता है। यह भी किया जा सकता है के तहत अनुमान है। इसका एकमात्र समाधान संचार है।

— वाइल्डकार्ड

@Wildcard: हाँ, मुझे लगता है कि phrasing बहुत अनुमोदित हो सकता है। जो आप कहने की कोशिश कर रहे हैं वह ज़ेनो के विरोधाभास की याद दिलाता है लेकिन कम सम्मोहक है।

— whatsisname