2009-09-16 14 views
7

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

एगिल प्रचारकों के सभी ब्लॉग पोस्ट और न्यूज़कास्ट देखते समय, आप केवल खुले दायरे या खुले "समय" परियोजनाओं के बारे में सुनते हैं। आप फिक्स लागत परियोजना पर इसे कैसे लागू करते हैं?

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

और निश्चित लागत वाली परियोजनाओं के बढ़ते प्रतिशत के साथ यह एक वास्तविक मुद्दा होने के लिए मेरे साथ है।

तो सवाल होगा:

  • आप कैसे एक ठीक लागत परियोजना में गुंजाइश प्रबंधन कैसे करूँ?
  • आप कैसे निर्धारित करते हैं कि सुविधाओं की इच्छा मूल दायरे से बाहर है या नहीं?
+1

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

+1

प्रत्येक स्प्रिंट के बाद "अस्पष्ट इच्छा सूची" को अपडेट नहीं किया जाना चाहिए ताकि उत्पाद स्वामी निर्णय ले रहा हो कि ध्यान केंद्रित कहाँ है? –

+0

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

उत्तर

6

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

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

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

0

मैंने हाल ही में similar question on SO का उत्तर दिया। आप उस उत्तर को उपयोगी पा सकते हैं।

+1

अच्छा जवाब। मुझे आपका बयान मिल गया है कि विकास टीम कुछ देने के लिए गुणवत्ता को कम कर देती है जो डरावनी सच है। – Dejan

+0

यही कारण है कि कई सॉफ्टवेयर परियोजनाएं मूल उम्मीदों को पूरा करने में विफल रही हैं। –

0

ठीक है, यह आदर्श आदर्श नहीं होगा जिसे आप ढूंढ रहे हैं, लेकिन कम-से-कम मदद कर सकते हैं।

अपना पहला बिंदु के लिए:

चुस्त साथ

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

5x Sprints = x Cost with minimal scope change:

विकल्प यहाँ उदाहरण के लिए गुंजाइश स्प्रिंट successions तय कर दी है, तो है।

अपने दूसरे बिंदु के लिए:

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

बंद होने पर, आपको 100% से अधिक खींचने में सक्षम होने के लिए अपने ग्राहकों के साथ बहुत अच्छी तरह से योजनाबद्ध दस्तावेज़ीकरण के साथ-साथ बहुत ठोस अनुबंधों की आवश्यकता होगी।

मुझे उम्मीद है कि इससे मदद मिलती है।

+0

यह सिर्फ चीजों का मेरा विचार है। मुझे कहना होगा कि मैं स्क्रम का बड़ा प्रशंसक हूं। लेकिन मैं गिरने के बारे में नहीं पढ़ सकता कि हम "अगर हमारे पास एक हथौड़ा है तो सभी समस्याएं एक नाखून की तरह दिखती हैं" समस्या में चल रही हैं। – Dejan

0

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

आप टैग करने योग्य डिलिवरेबल्स में इच्छा-धोखे की इच्छा सूची/आवश्यकताओं/स्क्रीनशॉट को तोड़ देते हैं। जैसे एक ग्राहक कह सकता है "मैं पेपैल के साथ ईकॉमर्स चाहता हूं", आपको इसे वास्तविक डिलिवरेबल्स में तोड़ना होगा। "1. ग्राहक पंजीकरण और लॉगिन, 2. उत्पाद कैटलॉग, 3. शॉपिंग बैग, 4. भुगतान, 5. ऑर्डर स्वीकृति"। इस स्तर पर, यह निर्धारित करना अभी भी असंभव है कि यह कितना समय लगेगा, और हमें परियोजना को पूरा करने के लिए उपरोक्त सभी को वितरित करने की आवश्यकता है (यानी आपके पास भुगतान के बिना ईकॉमर्स नहीं हो सकता है)। तो उन्हें दोबारा तोड़ दो, और फिर, जब तक कि आपके पास दानेदार डिलिवरेबल्स न हों, घंटों के भीतर वास्तविक रूप से डिलीवर करने योग्य, शायद दिन, लेकिन निश्चित रूप से सप्ताह नहीं।

1 Catalogue 
1a View all Items 
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row 
1aii View 10 items per page with paging 
1aiii View a user slected number of items per page, with paging 
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row 

1b View by Category 
... 
1c Search 
... 
1d Attribute Filter 
... 

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

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

उपरोक्त सभी स्पष्ट रूप से केवल एक छोटा सा हिस्सा है जो स्क्रम या किसी भी चुस्त प्रक्रिया है।

+0

यदि हम ग्राहकों को छोटे peaces में नीचे सूचीबद्ध करना चाहते हैं, तो हम बड़े ऊपर के डिजाइन और स्क्रम के बीच की रेखा को आकर्षित करते हैं। क्योंकि हम जानते हैं कि बीयूएफडी काम नहीं करता है। तो यहां मुझे यह सही करने के तरीके की एक छोटी सी समस्या दिखाई देती है। – Dejan

+0

मैं सहमत हूं, इसमें कुछ निर्णय लेता है। टेक्निकल स्पेक की बजाय इसे पहला मसौदा कार्यात्मक नमूना बनने के बारे में सोचें, आप केवल यह मानना ​​चाहते हैं कि उपयोगकर्ता दृष्टिकोण से कुछ कैसे काम करता है, आपको सबकुछ निर्दिष्ट करने की आवश्यकता नहीं है। उदाहरण के लिए, मैंने पेजिंग को मीटिंग किया है, लेकिन यह नहीं कि मैं इसे कैसे कार्यान्वित करूं, या उपयोगकर्ता इसके साथ कैसे बातचीत करेगा (क्या यह एक लिंक है, या एक ड्रॉप डाउन, क्या मैं वापस जा सकता हूं, आगे बढ़ सकता हूं, पेज पर जा सकता हूं?)। आप इसे लटका पाने के लिए यूआई मॉकिंग टूल (मुझे बाल्सामीक मॉक्स पसंद करते हैं) का उपयोग भी कर सकते हैं, यदि आप इसे नकल नहीं कर सकते हैं, तो आप बहुत जटिल यूआई तत्वों तक ही सीमित हैं, यह बहुत जटिल है। –

0

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

फिर आप सामान्य स्क्रम काम करते हैं ग्राहक वर्तमान यात्रा करने के लिए कहानियों का आवंटन, आदि

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

चाल, ज़ाहिर है, प्रत्येक कहानी/कार्य ;-)

+2

समस्या प्रारंभिक बैकलॉग बनाने के लिए नहीं है, यह अनुमान लगाया गया है और अनुमानों को स्थिर करने के लिए है। एक डबल कमी है: 1. आपको सबसे बुरे पल पर अनुमान लगाना होगा (जब आप परियोजना के बारे में कम जानते हैं) 2. आप उन्हें बाद में नहीं बदल सकते हैं। यह स्क्रम के साथ वास्तव में संगत नहीं है जो आपके द्वारा सीखने के निरंतर पुन: अनुमान की अनुमति देता है और बढ़ावा देता है। –

+0

उपरोक्त टिप्पणी में मुझे एक साथ उन दोनों में शामिल होना मुश्किल लगता है। यही कारण है कि इस सवाल से पूछा गया था। सिंगलशॉट के अच्छे उत्तर के लिए – Dejan

+0

+1। @ पास्कल/डीजन: कहानी अंक/लागत घंटों के बराबर नहीं है; दोनों के बीच सिर्फ एक सहसंबंध है। यह योजना पोकर के साथ किया जा सकता है। इससे कोई फर्क नहीं पड़ता कि एक +/- 25% गलतता है, जब तक यह औसत हो। इस परियोजना के दौरान कहानी का आदान-प्रदान किया जा सकता है क्योंकि स्क्रैम दृष्टिकोण को पारंपरिक झरना दृष्टिकोण के रूप में स्टीयरिंग के लिए अधिक स्वतंत्रता है। परिवर्तन अतिरिक्त लागत के बजाय निश्चित मूल्य के अंदर शामिल किया जा सकता है। निश्चित मूल्य/निश्चित क्षेत्र लगभग असंभव है (अक्सर तय समय और निश्चित गुणवत्ता भी मानते हैं)।यह एक अच्छा अनुमान है। – Adriaan

0

परियोजना छोटे भागों में विभाजित किया जा सकता है और निर्धारित दरों उन के साथ संलग्न किया जा सकता था के लिए लागत और समय का आकलन में अच्छा हो रहा है। परियोजना के अन्य चरणों को तब समायोजित किया जा सकता है।

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

10

मेरे लिए, Agile और निश्चित मूल्य के बारे में संक्षिप्त उत्तर यह है कि आप कम से कम एक निश्चित दायरे के साथ नहीं कर सकते हैं।

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

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

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

वैसे भी विभिन्न एजिल अनुबंधों का एक अच्छा संकलन है: 10 Contracts for your next Agile Software Project जो सहायक हो सकता है। लेकिन मुझे लगता है कि उन्हें सभी को ग्राहकों की कुछ शिक्षा की आवश्यकता होती है, खासतौर पर वह जिसका उपयोग निश्चित दायरे (और देर से प्रसव के साथ) निश्चित मूल्य के लिए किया जाता है।

+0

मैं 1000% से सहमत हूं। प्रगति की निगरानी और कार्यात्मक क्षेत्रों को प्राथमिकता देने के लिए शेयरधारकों को नियमित चेकपॉइंट का हिस्सा होना चाहिए। यदि एक निश्चित समय में एक निश्चित सुविधा सेट पर आग्रह किया जाता है, तो हितधारक को चुस्त प्रक्रिया से लाभ नहीं होता है। सभी टीमों (तकनीकी और व्यापार दोनों) से पूर्ण निवेश के बिना प्रक्रिया असफल होने के लिए नियत है - और यदि असफल नहीं है, तो बेकार के पास होना। –

0

निश्चित लागत का मतलब एकल स्प्रिंट नहीं है। स्कोप उत्पाद बैकलॉग में स्थानांतरित हो जाता है, और जैसे ही स्पिंट्स प्रगति होती है, दायरा समायोजित, बातचीत और वितरित किया जाता है। स्क्रम तेजी से मूल्य वितरण के लिए अनुमति देता है, और त्वरित सत्यापन प्रदान करता है, और संभावित सोना चढ़ाना पहचानने का अवसर प्रदान करता है।

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

यदि दायरा बढ़ता है (और मूल्य जोड़ता है), और लागत तय की जाती है, तो ट्रिपल बाधा (लागत, समय और दायरा) तदनुसार प्रबंधित की जानी चाहिए।

याद रखें कि निश्चित लागत का मतलब निश्चित लंबाई नहीं है।

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