सॉफ्टवेयर परियोजनाओं का मूल्यांकन या पूरी राशि शर्तों के योग के बराबर है?

अगले क्रॉस-पोस्ट (ओह, मुझे, बीच!) मेरे मुख्य ब्लॉग से।



इस लेख में, मैं उन चीजों के बारे में बात करने जा रहा हूं जो आप सभी लंबे समय से जानते हैं। आज मैं उनके बारे में सोचने का सुझाव देता हूं। <! Xml: namespace prefix = o ns = "urn: schemas-microsoft-com: office: office" /> <o: p> </ o: p>



यदि आप सॉफ़्टवेयर उद्योग में नए नहीं हैं, तो आप जानते हैं कि समय-समय पर कोई भी प्रबंधक एक ऐसे चरण में होता है जब वह अचानक समय, काम के अनुमानों में रुचि रखता है ... और आमतौर पर किसी भी तरह से नहीं, लेकिन कुछ फैशनेबल तकनीक के अनुसार। आपको एक सप्ताह में सूचित करने के लिए कहा जाता है कि बग्स के लिए कितना समय लगेगा जो अभी तक नहीं मिला है और यह सुविधा जिसका डिज़ाइन अभी तक पूरा नहीं हुआ है, इस तथ्य का उल्लेख नहीं करने के लिए कि नियोजित कार्य को निश्चित रूप से एक घंटे तक टुकड़ों में तोड़ दिया जाना चाहिए, अगर यह हर मिनट संभव नहीं है। .. <o: p> </ o: p>



प्रोजेक्ट टाइम को आमतौर पर कैसे अनुमानित किया जाता है? हर कोई जानता है कि बड़े टुकड़े का मूल्यांकन करना व्यावहारिक रूप से असंभव है, इसलिए इसे छोटे टुकड़ों में विभाजित किया जाता है, और फिर इन छोटे टुकड़ों को एक साथ रखा जाता है, उदाहरण के लिए, कुछ गैंट चार्ट या कैलेंडर या एक्सेल पर। <O: p> < / ओ: पी>



आज मैं इस तकनीक के तहत दो पूरी तरह से गलत धारणाओं के बारे में बात करना चाहूंगा। <O: p> </ o: p>



शुरू करने के लिए, परियोजना के समय या परियोजना के चरण का अनुमान क्या है? <O: p> </ o: p>



नहीं, नहीं, मैं समझता हूं कि प्रबंधन की प्रत्याशा में, आप, कसंद्रा के रूप में, भविष्य के बारे में बिल्कुल सटीक भविष्यवाणी करना चाहिए, और कसंद्रा के विपरीत, यह अधिक आशावादी नहीं है क्योंकि व्यवसाय के सिद्धांतों की आवश्यकता है (मुझे नहीं पता कि यह कैसे अनुवाद करता है, अच्छी तरह से। साम्यवाद के युवा बिल्डर का एक नैतिक कोड जैसा कुछ - इसके अनुसार हमारे पास हर साल अनिवार्य प्रशिक्षण है)। सामान्य तौर पर, हर कोई समझता है कि यह मुश्किल है, लेकिन आपकी भविष्यवाणियों को "पर्याप्त रूप से अच्छा होना चाहिए!" सभी दृष्टिकोणों से। <O: p> </ o: p>



ठीक है, जब प्रबंधकों का कहना है कि, यह समझने योग्य है। लेकिन हम प्रबंधक नहीं हैं, हम इंजीनियर हैं, तकनीकी हैं। हम जानते हैं कि "बहुत अच्छा" बहुत कुछ है। और इंजीनियरिंग अनुशासन का हिस्सा होने के लिए, एक अवधारणा को संख्याओं में औसत दर्जे का होना चाहिए। यही है, मैं स्पष्ट रूप से "अच्छा पर्याप्त" या अभी भी "अच्छा पर्याप्त" नहीं कहने के लिए किसी तरह इस मामले को मापना चाहता हूं। और जब एक इंजीनियर कुछ मापना चाहता है, तो वह ऐसे हानिकारक विज्ञान - गणित का उपयोग करता है। वह हानिकारक है क्योंकि वह लगातार प्रबंधकों के बारे में बात करती है कि वह उनके बारे में क्या सोचती है, और यहां तक ​​कि सही भी हो जाता है ... <o: p> </ o: p>



तो, और गणित में एक अनुमान क्या है, गणितीय आंकड़ों और संभाव्यता सिद्धांत में अधिक सटीक है। और यह अंतराल है जिसमें अपेक्षित यादृच्छिक चर किसी दिए गए प्रायिकता के साथ आता है। एक यादृच्छिक मूल्य एक परियोजना में कितना समय लगेगा या एक अलग परियोजना कदम है। ऐसा लगता है कि यह आवश्यक है कि डॉक्टर ने निर्धारित किया है, लेकिन दी गई संभावना के साथ क्या करना है? <O: p> </ o:>



प्रबंधक से संपर्क करने की कोशिश करें और कहें, "80 प्रतिशत की संभावना के साथ यह परियोजना एक महीने में पूरी हो जाएगी।" वह आपको क्या बताएगा?



हाँ, क्या आपको पहले से ही थोड़ी अस्वस्थता महसूस हुई है? और बेहतर। वह "निश्चित रूप से" चाहता है, लेकिन गणित क्या कहता है? कुछ आदतन वितरण की तस्वीर की कल्पना करें, कहें, एक पॉइसन या सामान्य-गौसियन वितरण। क्या अंतराल है जो 100 प्रतिशत हिट होने की संभावना है? यह सही है, अफसोस, अगर एक प्रबंधक एक गारंटीकृत मूल्यांकन चाहता है, तो गणितीय रूप से यह हमेशा अनंत है। ठीक है, या व्यावहारिक रूप से, वह शब्द जिसके लिए परियोजना को आसानी से पीटा जाएगा। किसी भी परियोजना में विफलता का एक मौका है। अच्छे इंजीनियरों के लिए, जिन्हें अच्छे ग्रेड बनाने की अनुमति थी, विफलता का यह मौका कम है, और बुरे लोगों के लिए यह बहुत अधिक है, लेकिन फिर भी किसी भी परिस्थिति में यह शून्य के बराबर नहीं है। <O: p> </ o: p>



यही है, वोलेन-नोलेंस आपके ग्रेडों को हटा देंगे, जिन्हें आपका वादा माना जाएगा, हालांकि वास्तव में वे अस्सी, नब्बे, निन्यानबे प्रतिशत की संभावना के लिए ग्रेड होंगे ... <o: p> </ o: p>



तो, किसी प्रोजेक्ट या प्रोजेक्ट स्टेप का मूल्यांकन एक समय अंतराल होता है, जिसमें यह आपके लिए आरामदायक होने की संभावना के साथ फिट होगा। या आप कह सकते हैं कि एक आरामदायक जोखिम के साथ आप भीतर नहीं रह सकते। <O: p> </ o: p>



मान लीजिए कि आपने 80 प्रतिशत को चुना है (क्रमशः, 20 प्रतिशत नहीं मिलने के जोखिम के साथ)। हां, मुझे पता है, यह बहुत जोखिम भरा लगता है, लेकिन प्राकृतिक परिस्थितियों में प्रोग्रामर को देखते हुए, मुझे यह महसूस हुआ कि बहुमत के लिए भी 80 प्रतिशत अत्यधिक है। आमतौर पर, स्मार्ट मैनेजर डेवलपर की रेटिंग को कम से कम डेढ़ से दो गुना तक बढ़ाते हैं। <O: p> </ o: p>



तो, आपके पास एक परियोजना है, इसके दो चरण हैं। आपने अनुमान लगाया कि प्रत्येक चरण में 80 प्रतिशत की संभावना के साथ ढाई दिन लगेंगे। क्या इसका मतलब है कि पूरी परियोजना में 80 प्रतिशत की समान संभावना के साथ एक सप्ताह लगेगा? यदि आपको थेरवर से कम से कम थोड़ा याद है, तो आपने पहले ही उत्तर दिया कि नहीं, संभावना पूरी तरह से अलग होगी, अच्छी तरह से, विशेष रूप से विदेशी वितरणों को छोड़कर, जो आमतौर पर प्रकृति में नहीं होती है। <O: p> </ o: p>



अपने लिए देखें, एक सामान्य वितरण का उदाहरण दें। एक बड़ी नीली ऊर्ध्वाधर रेखा 80 प्रतिशत की संभावना के साथ एक ही परियोजना का समय है। चित्र समान मान t ₀ से विचलन को आगे और पीछे दिखाता है, और छायांकित क्षेत्र क्रमशः, ऐसे विचलन की संभावना को दर्शाता है। जैसा कि आप देख सकते हैं, हरे रंग का क्षेत्र गुलाबी की तुलना में बहुत बड़ा है, अर्थात, एक निश्चित समय से एक परियोजना को पछाड़ने की तुलना में एक निश्चित समय से पीछे रह जाना बहुत आसान है। मुझे लगता है कि तथ्य, किसी के लिए सहज रूप से आश्चर्यजनक नहीं है, है ना?



<o: p> </ o: p>



ऐसी मात्राओं के लिए सबसे लोकप्रिय वितरण के लिए - पॉइसन, चित्र समान होगा। जीवन में सामना किए गए अधिकांश वितरणों के लिए सामान्य रूप से। और इसका मतलब है कि अगर आपने दो प्रोजेक्ट चरणों का अनुमान ₁ और टी _{2 के} रूप में 80 प्रतिशत की संभावना के साथ दिया है, तो टी ₁ + टी ₂ 80 प्रतिशत की संभावना के साथ पूरी परियोजना का अनुमान नहीं होगा। <O: p> </ o: p>



अमूर्त समस्याओं के साथ अपने सिर को मूर्ख नहीं बनाने के लिए, आइए प्रश्न को थोड़ा और व्यावहारिक रूप से देखें। लेकिन क्या ऐसा होता है कि कोई व्यक्ति समय से पहले काम पूरा कर लेता है? खैर, कभी-कभी ऐसा होता है, लेकिन जैसा कि वे कहते हैं, एक नगण्य राशि है। आखिरकार, भले ही आप पहले खत्म कर लें, सबसे अधिक संभावना है कि आप कोड को साफ करने के लिए मुक्त किए गए समय का उपयोग करने के लिए खुश हैं, परीक्षण करें, एक बार फिर से सुनिश्चित करें, सही? दरअसल, मर्फी के नियम को समर्पित संग्रह में फैली रोजमर्रा की समझदारी केवल यह कहती है: "कोई भी काम इसके लिए आवंटित समय लेता है।" <O: p> </ o: p>



इस संशोधन के साथ, सब कुछ और भी हास्यास्पद हो जाता है। चूंकि, अगर हम यह मान लेते हैं कि काम योजनाबद्ध तरीके से कम नहीं है, तो परियोजना को t ₁ + t ₂ में फिट करना जारी रखने के लिए यह आवश्यक है कि दोनों कार्य नियोजित समय में पूरे हों, जो मुझे याद है, 80 प्रतिशत की संभावना के साथ अनुमानित किया गया था। अब यह गणित पर स्कूल की पाठ्यपुस्तक को बाहर निकालने और गणना करने का समय है कि पूरी परियोजना परियोजना में गिने गए समय को पूरा करने की संभावना है या जोड़कर भी: <o: p> </ o: p>



P (T1 & T2) = P (T1) * P (T2) = 0.8 * 0.8 = 0.64 <o: p> </ o: p>



यही है, अगर आपने परियोजना को केवल दो भागों में विभाजित किया है, तो प्रत्येक का मूल्यांकन 80 प्रतिशत संभावना के साथ किया है, तो राशि में केवल 64 प्रतिशत की "विश्वसनीयता" है! होमवर्क के रूप में प्रयास करें, क्या होगा यदि परियोजना दस चरणों में विभाजित हो? क्या आपने इसे आजमाया है? हाँ। दस प्रतिशत से थोड़ा अधिक। यहां तक ​​कि अगर आप 90% के प्रत्येक चरण के अनुमान के साथ इंजीनियरों को हिलाते हैं, तो आपके दस चरणों की परियोजना की संभावना केवल 35 प्रतिशत होगी। <O: p> </ o: p>



वैसे, यही कारण है कि जोएल स्पोलस्की ने अपने साक्ष्य आधारित निर्धारण ( http://www.joelonsoftware.com/items/2007/10/26.html ) में जोर दिया कि अनुमानों को जोड़ा नहीं जाना चाहिए, लेकिन मोंटे कार्लो विधि द्वारा चरण अनुमानों से प्राप्त किया गया है । <o: p> </ o: p>



बेशक, आप देख सकते हैं कि व्यक्तिगत आकलन की गुणवत्ता पूरे के मूल्यांकन की गुणवत्ता को बहुत प्रभावित करती है। इस प्रकार, 80 से 90 प्रतिशत तक के चरणों के अनुमान में सुधार से परियोजना के मूल्यांकन में दस चरणों से 10 से 35 प्रतिशत तक सुधार हुआ। लेकिन चलो ईमानदार हो, और 35 प्रतिशत आप के अनुरूप होगा? और आप केवल दस चरणों में कितनी बार प्रोजेक्ट करते हैं? और सौ कदम के साथ, यहां तक ​​कि प्रत्येक चरण के लिए 99 प्रतिशत संभावना के साथ बहुत उच्च-गुणवत्ता वाले कदम का अनुमान आपको अंत में पूरे प्रोजेक्ट के लिए 40 प्रतिशत से कम मौका देगा। क्या आप 40 प्रतिशत से खुश हैं? और जहाँ आप पाते हैं कि इंजीनियर केवल एक बार सौ में से एक बार गलती करते हैं और उसी समय टिप्पणी की एक पंक्ति लिखने के लिए पूरा दिन नहीं लेते हैं? <O: p> </ o: p>

बेशक, निष्पक्षता में, यह ध्यान दिया जाना चाहिए कि सफलता की संभावनाओं का ऐसा "पतन" केवल महत्वपूर्ण पथ पर कदम के लिए होता है। लेकिन यह मत भूलो कि यदि आप अपने संसाधनों (लोगों) का प्रभावी ढंग से उपयोग करते हैं, तो पर्याप्त रूप से छोटी देरी के साथ भी, कोई भी कदम महत्वपूर्ण पथ पर हो सकता है। तो ऊपर के उदाहरणों में स्थिति उतनी बुरी नहीं हो सकती है, लेकिन जितनी अच्छी होगी, उतनी अच्छी नहीं। हालाँकि, आप भी यह पहले से ही जानते हैं ... :-) <o: p> </ o: p>



बेशक, अब एक स्वाभाविक सवाल होगा, लेकिन क्या करना है? तुम्हें पता है, कुछ संभव है। लेकिन यह पहले से ही एक अलग लेख के लिए एक विषय है, और एक नहीं है। <O: p> </ o: p>



और वास्तव में "मैं" को संक्षेप में, इस लेख में मैंने क्या कहने की कोशिश की: <o: p> </ o:>



1. मूल्यांकन तब नहीं होता है जब परियोजना की जाती है। यह वह समय है जिस पर वह किसी दिए गए संभावना के साथ मिलेंगे। भले ही प्रबंधक या अभियंता को यह पता न हो, लेकिन यह अभी भी मौजूद है और इंजीनियर की आशावाद और प्रबंधक की आक्रामकता पर निर्भर करता है। "O: p> </ o: p>



2. प्रबंधन परियोजना मूल्यांकन में बड़ी त्रुटियों की एक संख्या का परिचय देता है, इंजीनियरों की तुलना में व्यक्तिगत चरणों का अनुमान जोड़कर, इन व्यक्तिगत चरणों का मूल्यांकन करता है। <O: p> </ o: p>



3. व्यक्तिगत चरणों का मूल्यांकन करने में भी छोटी त्रुटियां एक संपूर्ण परियोजना के मूल्यांकन की विश्वसनीयता को काफी कम कर सकती हैं। <O: p> </ o:>



4. और हमेशा की तरह, कैलकुलेटर मस्तिष्क की जगह नहीं लेता है, और Microsoft प्रोजेक्ट - प्रबंधन की कला। <O: p> </ p>:>



5. ओह, हाँ, एक और बात: अपने आप को एक मूर्ति मत बनाओ। जिसमें फैशनेबल तकनीकें शामिल हैं। <O: p> </ o: p>



<o: p>   </ o: p>