कोड शुरू करने से पहले सॉफ्टवेयर उत्पाद को कितनी अच्छी तरह परिभाषित किया जाना चाहिए?


13

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

मुझे पता है कि यह एक अच्छा विचार है कि भविष्य में जोखिमों से बचने के लिए अंतिम उत्पाद क्या हो सकता है, इसका एक अच्छा विचार है, लेकिन किसी उत्पाद को इतनी अच्छी तरह से परिभाषित नहीं करना भी महत्वपूर्ण है कि इसे अनुकूलित करना कठिन है परिवर्तन।

अन्य अधिक विशिष्ट प्रश्न संभवतः होंगे:

  1. किसी परियोजना के समय का कितना प्रतिशत आम तौर पर विकास से पहले नियोजन चरणों में खर्च किया जाता है?

  2. क्या आपके पास कुछ मापने योग्य मापदंड हैं जिन्हें आप कोड शुरू करने से पहले पूरा करने की कोशिश करते हैं या एक आंत से अधिक चीज है?

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

आप साझा करने के लिए तैयार हैं किसी भी अनुभव भयानक होगा!

जवाबों:


10

शाब्दिक उत्तर "कितनी अच्छी तरह परिभाषित किया गया है?" है

अच्छी तरह से परिभाषित है कि आप शुरू कर सकते हैं।

अच्छी तरह से पर्याप्त परिभाषित किया गया है कि आप काम के प्रारंभिक दायरे (एक प्रारंभिक अवधारणा के लिए) की पहचान कर सकते हैं। यह परिवर्तनों को पहचानने में मदद करने के लिए बस पर्याप्त है जो अनिवार्य रूप से होगा।

अच्छी तरह से पर्याप्त परिभाषित किया गया है कि आप स्प्रिंट को प्राथमिकता दे सकते हैं।

मैं उपयोग के मामलों को परिभाषित करने की बात कर रहा हूं,

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

जोखिम का विश्लेषण,

आम तौर पर समय की बर्बादी होती है।

ड्राइंग क्लास आरेख, आदि।

अगर यह मदद करता है।

किसी परियोजना के समय का कितना प्रतिशत आम तौर पर विकास से पहले नियोजन चरणों में खर्च किया जाता है?

यह बहुत भिन्न होता है। "आधिकारिक" नंबर प्राप्त करने के लिए सॉफ्टवेयर इंजीनियरिंग अर्थशास्त्र जैसी एक अच्छी पुस्तक खरीदें।

क्या आपके पास कुछ मापने योग्य मापदंड हैं जिन्हें आप कोड शुरू करने से पहले पूरा करने की कोशिश करते हैं या एक आंत से अधिक चीज है?

"मापने योग्य"। जिसे परिभाषित करना लगभग असंभव है।

"आंत"। बुरी नीति।

मुद्दा है "क्या आप समझते हैं कि आप क्या कर रहे हैं?"

यह एक आंत की बात नहीं है। यह एक हाँ / नहीं सवाल है।

यह "औसत दर्जे का" नहीं है क्योंकि यह सिर्फ एक हाँ / कोई सवाल नहीं है।

और, आगे, आपको प्राथमिकता देनी होगी। तुम सब कुछ नहीं करते। बस पहले कुछ स्प्रिंट को संभालने के लिए पर्याप्त है।

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

आप पहले से सब कुछ नहीं जान सकते।

कोशिश मत करो।


व्यक्तिगत रूप से मुझे लगता है कि क्लास डायग्राम लिखने में बहुत अधिक समय खर्च होता है क्योंकि आपके शुरू होने के बाद भी मॉडल और कोड में बदलाव होता है।
एंडर्सक

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

@ समय पोस्ट: अच्छा सुझाव है। यह सवाल में "कितनी अच्छी तरह से परिभाषित" परिभाषित करने का एक तरीका है। यह "गुंजाइश की पहचान करने और रेंगने में आपकी मदद करेगा।" ज्यादा नहीं, है ना?
एस.लॉट

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

@ हेन हेनरिक्स: मैंने आपकी बात को शामिल करने के लिए जवाब को थोड़ा मोड़ दिया। आरंभ करने के लिए पर्याप्त गुंजाइश परिभाषा। मुझे जोड़ने के लिए लुभाया गया है "और नहीं।"
S.Lott

2

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

यदि आपका ग्राहक दूर है और लंबी अवधि में प्रतिक्रिया के लिए उपलब्ध नहीं है, तो आपकी कल्पना बहुत विस्तृत होनी चाहिए।

हमारी कंपनी में हम उपयोगकर्ता कहानियां बनाते हैं और प्रोजेक्ट पर डेवलपर्स के साथ प्लानिंग पोकर खेलते हैं । यह हमें उपयोगकर्ता कहानी पर बिताए जाने वाले घंटों का उचित संकेत देता है।


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

यह एक महान बिंदु है, धन्यवाद! मैं इस बात पर विचार नहीं करता था कि किसी दिए गए प्रोजेक्ट के लिए क्लाइंट की भागीदारी कितनी तेजी से बदल सकती है। निश्चित रूप से कुछ मुझे ध्यान में रखना चाहिए। इसके अलावा, मैंने कभी भी "नियोजन पोकर" के बारे में नहीं सुना था और ऐसा लगता है कि यह वास्तव में मूल्यवान होगा।
drewag

2

प्रोजेक्ट को कितनी अच्छी तरह से परिभाषित किया जाना चाहिए, यह आपको शुरू करने के लिए पर्याप्त है और पता है कि आप अगले दो हफ्तों के लिए कहां जा रहे हैं।

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

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

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

किसी भी समय आपकी चयनित सुविधाओं की सूची का विस्तार हो सकता है, जब तक कि आप लक्ष्य के साथ मिलते हैं, अर्थात, आप दी गई अवधि के दौरान आपके द्वारा कहे गए सभी चीजों को विकसित करने में सक्षम हैं।

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

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

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

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

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

आशा है कि ये आपकी मदद करेगा! =)


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

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

1

ठीक है, जो मेरे लिए बहुत अच्छा काम करता है वह कार्यक्षमता "काफी अच्छी" निर्दिष्ट है और सॉफ्टवेयर वास्तुकला केवल बहुत ही विशिष्ट रूप से निर्दिष्ट करता है।

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

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

नरक, कभी-कभी मुझे यह भी पता नहीं होता है कि मैंने इसे गलत करने के बाद तक इसे सही तरीके से कैसे किया। मैं इसे एक बार बनाता हूं, इसे फाड़ता हूं, और इसे फिर से करता हूं, अब मुझे पता है कि कैसे। इस बिंदु पर मैं एक विस्तृत विस्तृत रूपरेखा तैयार कर सकता हूं और पुनः आरंभ कर सकता हूं।


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

1

आप किस भाषा और कार्यप्रणाली का उपयोग कर रहे हैं?

जावा और C ++ जैसी कुछ भाषाओं में, कॉमन लिस्प या पायथन (जावा की तुलना में C ++ जैसी भाषाओं की तुलना में अधिक प्रारंभिक संरचना की आवश्यकता होती है, क्योंकि जावा में Refactoring करना आसान है)। लियो ब्रोडी (मुझे लगता है कि "थिंकिंग फोर्थ" में) ने कोडिंग शुरू करने के बारे में सलाह के दो टुकड़े दिए: जितनी जल्दी आप फोर्थ में सहज महसूस करते हैं, बाद में दूसरी भाषा में चाहते हैं।

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

इसके अलावा, यह व्यक्तियों और सॉफ्टवेयर के प्रकार के साथ उनकी परिचितता पर निर्भर करता है। एक बिंदु पर, मुख्य रूप से CRUD एप्स करते समय, मैं कुछ स्पेक्स और कोरे नोट पेपर के 3 "x5" टुकड़े से शुरू होने वाला एक पूरा कार्यक्रम लिख सकता था। मैं अब जैसा लिखता हूं वैसा सामान नहीं लिख सकता।


परिप्रेक्ष्य के लिए धन्यवाद। जब परियोजना प्रबंधन की बात आती है तो मैंने यह नहीं सोचा था कि भाषा और मंच सर्वोत्तम प्रथाओं को कैसे प्रभावित कर सकते हैं। मैं ज्यादातर Object-C, UIKit और AppKit के बारे में बात करता हूं। हालाँकि मैं अन्य भाषाओं (C, C ++, C #, Java, Python, आदि) के एक समूह में भी काम करता हूँ। इसका मतलब है कि मुझे सावधान रहना चाहिए कि सभी परियोजनाओं के लिए एक निश्चित तरीका सबसे अच्छा नहीं होगा, मुझे लक्ष्य पद्धति और भाषा के आधार पर अपनी कार्यप्रणाली का आधार समायोजित करना चाहिए (और अगर मेरे पास कोई भाषा है, तो उसके आधार पर भाषा चुनें)।
drewag

1

यहां दो उपयोगी शब्द MVP (न्यूनतम व्यवहार्य उत्पाद) और MMF (न्यूनतम विपणन सुविधा) हैं। एमएमएफ एक फीचर का सबसे छोटा संस्करण है जो व्यावसायिक मूल्य प्रदान करता है। एक एमवीपी सबसे कम एमएमएफ है जो एक उत्पाद के रूप में व्यवहार्य है। एक परियोजना शुरू करते समय, सबसे अच्छी बात यह है कि एमएमएफ और एमवीपी की पहचान करें और वहां से शुरू करें।

जैसे ही यह व्यवहार्य हो, अपने उत्पाद को जारी करें, फिर इसे लगातार बढ़ाते रहें।


यह वास्तव में महान शब्दावली है, धन्यवाद! यह कुछ औसत दर्जे की चीज के साथ आने के लिए यहाँ की सबसे अच्छी बात है। बेशक, यह सही नहीं है, लेकिन ऐसा लगता है कि यह तय करना काफी आसान होगा कि क्या कोई फीचर विपणन योग्य है और / या यह उत्पाद में मूल्य जोड़ता है।
drewag
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.