क्या कार्यात्मक आवश्यकताओं की कमी चुस्त है?


10

आजकल हर कोई फुर्तीला बनना चाहता है। मैंने जिस भी टीम के साथ काम किया, उसमें फुर्तीली की आकृति अलग थी। कुछ चीजें सामान्य हैं - जैसे दैनिक स्टैंड-अप या योजना, लेकिन अन्य भागों में काफी भिन्नता है।

मेरी वर्तमान टीम में एक विस्तार है जो मुझे परेशान करता है। यह कार्यात्मक आवश्यकताओं की कमी है। न केवल अपेक्षाओं का कोई लिखित रूप है, बल्कि उन कार्यों में भी है जो अस्पष्ट रूप से परिभाषित हैं कि क्या करने की आवश्यकता है।

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

इसलिए मैं सोच रहा हूं - क्या पुरानी प्रणाली के पुनर्लेखन के मामले में कोई व्यावसायिक आवश्यकता नहीं है?


1
क्या पुरानी प्रणाली तब तक उपयोग में रहेगी जब तक कि नई प्रणाली इसकी जगह नहीं लेती है, या दोनों प्रणालियां एक साथ उपयोग की जाएंगी, नई प्रणाली धीरे-धीरे पुरानी प्रणाली में कार्यों की जगह ले सकती है?
ग्रेग बरगार्ड

1
@GregBurghardt दूसरा विकल्प
Landeeyo

1
वैसे, आपकी टीम की योजना क्या है? क्या आप उन्हें इकट्ठा करने, व्यवसाय से जुड़े लोगों से बात करने जा रहे हैं, आदि?
फिलिप मिलोवानोविक

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

3
मैं वास्तव में उस नाजुक को बुलाऊंगा।
मेसन व्हीलर

जवाबों:


21

कार्यात्मक आवश्यकताओं की कमी है या नहीं, यह चुस्त दुरस्त है। जब आप यह नहीं जानते कि सिस्टम कैसे काम करता है तो आप एक सिस्टम का पुनर्निर्माण नहीं कर सकते।

आपको व्यवसाय के स्वामी को यह बताने की आवश्यकता है कि आपको पता नहीं है कि पुरानी प्रणाली कैसे काम करती है।

आपका सबसे अच्छा विकल्प अपने व्यवसाय के मालिक या कुछ अनुभवी उपयोगकर्ताओं के साथ काम करना है, खेल में व्यावसायिक प्रक्रियाओं को समझना और अपनी स्वयं की स्वीकृति परीक्षणों को विकसित करना है। यदि आप कुछ अंतिम उपयोगकर्ताओं के साथ काम कर सकते हैं तो आपको इस बारे में अधिक प्रतिक्रिया मिल सकती है कि पुरानी प्रणाली कैसे काम करती है।

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

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

आपको निम्न में से एक मिलेगा:

  • उचित आवश्यकताओं और एक तेजी से विकास चक्र
  • आवश्यकताओं को इकट्ठा करने और सॉफ्टवेयर के पुनर्निर्माण का समय
  • एक नया प्रोजेक्ट जो आपके करियर पर एक काला निशान नहीं होगा

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

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


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

16

फुर्तीली कार्यात्मक आवश्यकताओं की आवश्यकता को नहीं बदलता है, लेकिन यह आम तौर पर बदलता है कि आप उन्हें कैसे इकट्ठा करते हैं। गैर-चुस्त तरीका किसी को लंबी प्रक्रिया से गुजरने के लिए है, फिर आपको सिस्टम के लिए सभी आवश्यकताओं वाले किसी प्रकार के दस्तावेज़ दें।

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

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

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


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

4

आवश्यकताओं को पकड़ना किसी भी (सफल) सॉफ्टवेयर परियोजना का एक अनिवार्य हिस्सा है। लेकिन आवश्यकताओं को लिखना विनिर्देशन नहीं है।

  • एक दस्तावेज-केंद्रित दृष्टिकोण, चीनी फुसफुसाते हुए एक खेल की तरह समाप्त हो सकता है: एक विषय वस्तु विशेषज्ञ एक आवश्यकता की आवाज लगाता है, एक विश्लेषक इसे लिखता है, एक देव कुछ लिखने की कोशिश करता है जो विश्लेषक के विवरण से मिलता है, अंत उपयोगकर्ता उलझन में है क्योंकि सॉफ्टवेयर नहीं करता है 'उनकी समस्या का समाधान नहीं है।

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

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

  • समय के साथ आवश्यकताओं की शिफ्टिंग की समझ के अनुसार, स्थैतिक आवश्यकताओं के विनिर्देश की तारीख से बाहर हो जाएगा। इसे कैसे रोका जा सकता है?

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

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

आसपास काम करने वाली प्रणाली का होना भी नए सॉफ्टवेयर के परीक्षण के लिए बहुत मददगार हो सकता है, लेकिन यह किसी भी फुर्तीली-ईश चिंताओं से संबंधित नहीं है।

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

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


1

यहां हमने यह कैसे किया। हमने मालिकों से बात की। हमने प्रबंधकों से बात की। हमने काम कर रहे उपयोगकर्ताओं से बात की। हमने एक उपयोगकर्ता के डेस्क पर बैठकर और (और सवाल पूछते हुए) आश्चर्यजनक रूप से उपयोगी पाया। प्रबंधकों को पता था कि हमें किन उपयोगकर्ताओं के साथ बैठना चाहिए।

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

इसलिए जब एजाइल सिस्टम के कुछ हिस्सों को जल्दी से उतार सकता था, तो दूसरों को कुछ और सोचना होगा और इससे पहले कि हम शुरू कर सकें।


0

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


0

यह सवाल इशारा करता है कि चुस्त आंदोलन में क्या गलत हुआ। यह सवाल पूछने वाले व्यक्ति की कोई गलती नहीं है; मैं हर समय इस जाल में पड़ता हूँ क्योंकि कॉर्पोरेट जीवन के वर्षों ने मुझे प्रशिक्षित किया।

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

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

क्या लगातार रिलीज, चर्चा, सीखना, वापस जाना और सॉफ्टवेयर बदलना होगा? क्या आप निर्माण कर रहे हैं? सॉफ्ट वेयर या हार्डवेयर का ?

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

योजना में छिद्रों की पहचान करना दोष खोजने के बारे में नहीं है, इसका सिर्फ सॉफ्टवेयर विकास है।

इस कारण से, मुझे गाइ का जवाब पसंद है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.