साक्ष्य आधारित योजना

अनुवादक का नोट: मूल लेख 2007 में लिखा गया था, हालांकि, मेरी राय में, यह आज भी पूरी तरह से प्रासंगिक है।

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

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


बस चिल्लाओ! यदि आप अभी भी प्रफुल्लित हैं।

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

डेवलपर्स औपचारिक रूप से अपनी गतिविधियों की योजना क्यों नहीं बनाते हैं? इसके दो कारण हैं। सबसे पहले, यह एक बड़ी बवासीर है। दूसरे, कोई भी यह नहीं मानता है कि योजनाएं वास्तविकता के अनुरूप होंगी। अगर वे अभी भी गलत हैं तो समय व्यर्थ क्यों करें।

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



स्टेटर कर्व, अधिक यथार्थवादी विशिष्ट प्रोजेक्ट पूरा होने की तारीख।
यहाँ यह कैसे करना है।

1. साझा करें ...

जब मैं एक शेड्यूल देखता हूं, तो व्यक्तिगत कामों को दिनों या हफ्तों में मापा जाता है, मैं समझता हूं कि इसमें कोई अर्थ नहीं होगा। घंटों में मापा गया, बहुत छोटे कार्यों में नियोजित गतिविधि को तोड़ना आवश्यक है। अधिकतम 16 घंटे।

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

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

अधिकतम कार्य अवधि 16 घंटे निर्धारित करके, आप अपने आप को इस लानत कार्यक्षमता पर विचार करने के लिए मजबूर करते हैं। लेकिन अगर आप "अजाक्स फोटो एडिटर" नामक तीन सप्ताह के काम से हट जाते हैं, तो मेरे लिए बुरी खबर है: इस समय से आप आधिकारिक तौर पर बर्बाद हो चुके हैं । कार्य को पूरा करने के लिए ठोस कदम के बारे में सोचने के बिना, आप अनिवार्य रूप से उनमें से कई के बारे में भूल जाएंगे।

2. खर्च किए गए समय की गणना करें

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

वास्तव में, कुछ भी नहीं।

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



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

• एक पौराणिक मूल्यांकनकर्ता जो केवल आपकी कल्पना में मौजूद है, हमेशा लीड समय की सटीक भविष्यवाणी करेगा। उसकी गति इतिहास {1, 1, 1, ...} जैसी दिखाई देगी
• एक विशिष्ट खराब मूल्यांकक संकेतक की बहुत विस्तृत श्रृंखला दिखाएगा, उदाहरण के लिए {0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13%}
• अधिकांश विशेषज्ञ, निश्चित रूप से, गलत होंगे, लेकिन सामान्य तौर पर उनका मूल्यांकन अच्छा होगा। कार्य को हमेशा नियोजित की तुलना में अधिक समय की आवश्यकता होती है - त्रुटियों के सुधार, बैठकों की योजना, कॉफी विराम और उस पागल व्यक्ति को ध्यान में रखना बहुत मुश्किल है जो आपको लगातार विचलित करता है। यह विशिष्ट मूल्यांकनकर्ता गति के काफी स्थिर मूल्यों को दिखाएगा, जो, हालांकि, एकता से कम हैं। उदाहरण के लिए, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}

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

यदि एक नया मूल्यांकक आपकी टीम में आता है, जिसके पास अभी तक संचित डेटा नहीं है, तो सबसे बुरा मान लें - उसे एक झूठी कहानी दें, जब तक कि वह आधा दर्जन वास्तविक कार्यों का सामना नहीं कर सकती।

3. भविष्य का मॉडल बनाएं

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

किसी दिए गए डेवलपर के लिए संभावित परिणाम की गणना करने के लिए, आपको चरण 2 में एकत्रित इस डेवलपर के आंकड़ों से समस्या के प्रत्येक आकलन को यादृच्छिक रूप से चयनित गति में विभाजित करना होगा। उदाहरण के लिए



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

देखो क्या होता है

• पौराणिक आदर्श मूल्यांकक के मामले में, सभी गति एकता के बराबर हैं। गति से विभाजित करना, जो हमेशा एकता के बराबर होता है, कुछ भी नहीं बदलता है। इस प्रकार, सभी मॉडलिंग दौर एक ही पूरा होने की तारीख देते हैं, और इस तिथि में 100% संभावना है। ठीक एक परी कथा की तरह!
• खराब विशेषज्ञ की रेटिंग बहुत बिखरी हुई है। यह या तो 0.1 या 13.0 हो सकता है। सिमुलेशन के प्रत्येक चरण में बाकी हिस्सों से बहुत अलग परिणाम होता है। संभावना वितरण वक्र अत्यंत कोमल होगा, कल या दूर के भविष्य में समाप्त होने की समान संभावना दिखाएगा। वैसे, यह काफी उपयोगी जानकारी है - यह आपको बताता है कि आप उत्पाद के लिए नियत रिलीज़ तिथि के बारे में सुनिश्चित नहीं हो सकते।
• औसत विशिष्ट मूल्यांकनकर्ता गति का एक बहुत करीबी सेट देगा, उदाहरण के लिए, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}। इन गति से विभाजित करके, आप कार्यों के लिए आवंटित समय में वृद्धि करेंगे, उदाहरण के लिए, मॉडलिंग के एक चरण में 8 घंटे का कार्य 13 घंटे के कार्य में बदल सकता है, दूसरे के दौरान 15 घंटे का समय लगेगा। यह मूल्यांकनकर्ताओं के दुर्गम आशावाद के लिए क्षतिपूर्ति करता है। इसके अलावा, इस विशेष डेवलपर में निहित आशावाद, सिद्ध और समय-परीक्षण के आधार पर, मुआवजे का सटीक प्रदर्शन किया जाएगा। और चूंकि वास्तविक गति मूल्य में काफी करीब है (लगभग 0.6), मॉडलिंग के प्रत्येक दौर को शुरू करने पर, आपको समान संख्याएं मिलेंगी, और परिणामस्वरूप, आपके पास परियोजना के पूरा होने के लिए संभावित तारीखों की काफी संकीर्ण सीमा होगी।

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

जुनूनी-बाध्यकारी विकार की आवश्यकता नहीं है

अपने मछली पकड़ने के दौरे के बारे में अपने मालिक की अंतहीन कहानियों का क्या करें? या बिक्री बैठकों के साथ जो आपको बिना किसी स्पष्ट कारण के भाग लेने के लिए मजबूर करते हैं? कॉफी टूट जाती है? एक कार्यस्थल को स्थापित करने में मदद करने के लिए आधा दिन बिताया?

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



बेशक, आप बस इतना कर सकते हैं कि अगर आप चाहें। और सबूत-आधारित योजना काम करना जारी रखेगी।

लेकिन आपके पास नहीं है ।

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

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

private int width; public int getWidth () { return width; } public void setWidth (int _width} { width = _width; } 

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

जैसा कि यह हो सकता है, प्रत्येक एक्सेस पद्धति के कार्यान्वयन में उसे दो घंटे लगते हैं। यानी कार्यों के निष्पादन समय के उनके अनुमान इस प्रकार हैं:

{२, २, २, २, २, २, २, २, २, २, २, २ ...}

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

{२, २, २, २, ४, २, २, २, २, ४, २, ...}

और तदनुसार गति

{, 1, 1, 1, 1, 0.5, 1, 1, 1, 1, 0.5, 1, ...}

अब सोचिये क्या होता है। मोंटे कार्लो सिमुलेशन में, संभावना है कि प्रत्येक ग्रेड को 0.5 से विभाजित किया जाएगा, संभावना है कि जॉन की नौकरी बॉस द्वारा बाधित हो जाएगी। इस प्रकार, डीपी सही अनुसूची का उत्पादन करेगा !

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

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

... और किसी भी मामले में, डीपी समान, पूरी तरह से सटीक परिणाम देगा , चाहे आप किस प्रकार के निष्क्रिय-आक्रामक डेवलपर के साथ काम कर रहे हों।

4. सक्रिय रूप से अपनी परियोजना का प्रबंधन

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



आप प्रत्येक डेवलपर के लिए संभावित पूर्ण तिथियों का वितरण भी देख सकते हैं:



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

परियोजना की सीमाएँ

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

आदर्श रूप से, इस सब के लिए विशेष बफ़र्स प्रदान किए जाने चाहिए। और सच्चाई यह है - अपनी योजनाओं के लिए बफ़र्स जोड़ें

1. कार्यक्षमता पर नए विचार
2. प्रतियोगी प्रतिक्रियाएँ
3. एकीकरण (एक प्रणाली में विभिन्न डेवलपर्स द्वारा लिखित कोड का संयोजन)
4. डिबग का समय
5. प्रयोज्यता परीक्षण (और अंतिम उत्पाद में परीक्षण के परिणाम का उपयोग करके)
6. बीटा परीक्षण

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

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



एक्स अक्ष पर हम गणना की तारीख को चिह्नित करते हैं, वाई परियोजना के पूरा होने की तारीख है। आकृति में तीन वक्र दिखाए गए हैं: ऊपरी एक 95% संभावना वाले परिणामों से मेल खाती है, औसत एक 50% और निचला एक से 5% से मेल खाती है। ये वक्र एक-दूसरे के जितने करीब होते हैं, हमारे पास इस परियोजना के पूरा होने की संभावित तिथियों की सीमा उतनी ही कम होती जाती है।

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

वैसे

यहाँ कुछ चीजें हैं जो मैंने प्रोजेक्ट प्लानिंग के वर्षों में महसूस की हैं।

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

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

प्रबंधक ऐसा क्यों करते हैं?

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

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

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

आप n से 4n प्राप्त नहीं कर सकते, आप इसे प्राप्त नहीं कर सकते, और यदि आपको लगता है कि आप सफल हुए हैं, तो मुझे अपनी कंपनी का एक टिकर भेजें और मैं इसे कम कर दूंगा।

vmarunin टिकर टिप्पणी व्याख्या
"... मुझे एक टिकर भेजें ताकि मैं इसे छोटा कर सकूं"
छोटा करने के लिए (एक छोटी स्थिति खोलने के लिए) शेयरों को उधार लेना है, उन्हें बेचना है, और जब वे कीमत में गिरते हैं, तो शेयर खरीदते हैं और ऋण को चुकता करते हैं।
दूसरे शब्दों में, जोएल इस तथ्य पर पैसा लगाने के लिए तैयार है कि अगर कोई कंपनी विकास की अवधि को 4n से घटाकर n कर सकती है, तो यह निश्चित रूप से जल्द ही एक्सचेंज पर आ जाएगी।

4. अनुसूची लकड़ी के ब्लॉक वाला एक बॉक्स है । मान लीजिए कि आपके पास कई लकड़ी के ब्लॉक हैं जिन्हें एक बॉक्स में नहीं रखा जा सकता है, तो दो विकल्प हैं: एक बड़ा बॉक्स लें या कई ब्लॉकों से छुटकारा पाएं। यदि आप परियोजना को 6 महीने में वितरित करना चाहते हैं, और कार्य योजना के अनुसार यह 12 हो जाता है, तो आपको केवल रिलीज की तारीख को स्थगित करना होगा, या कुछ कार्यों को छोड़ देना होगा। आप केवल लकड़ी के ब्लॉक को नहीं ले सकते हैं और कम कर सकते हैं।

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

कल्पना कीजिए कि आप दो कार्यों के साथ आए हैं। पहला, बहुत उपयोगी, आपके उत्पाद को वास्तव में सुंदर बना सकता है। अन्य बेहद सरल है, और प्रोग्रामर उस पल का इंतजार नहीं कर सकते जब वे इसे सांकेतिक शब्दों में बदलना ("देखो! <पलक>!") कर सकते हैं, हालांकि यह किसी भी वास्तविक लाभ को सहन नहीं करता है।

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

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

जब मैं एक्सेल 5 पर काम कर रहा था, तो हमारी नियोजित कार्यक्षमता की सूची बहुत बड़ी थी, जिसने रिलीज शेड्यूल के पीछे बहुत गंभीर अंतराल को चित्रित किया। "मेरे भगवान," हमने सोचा, "ये सभी बहुत महत्वपूर्ण चीजें हैं। मैक्रो एडिटिंग विज़ार्ड के बिना हम कैसे रहेंगे? ”

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

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

निष्कर्ष

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

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

इस विधि नाम का अनुवाद करने में मेरी मदद करने के लिए Truezemez का धन्यवाद।