सॉफ्टवेयर परियोजनाओं में मूल्यांकन और योजना - बिना नकदी के

दोस्तों, शुभ दोपहर!

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

प्रदर्शन और करीब एनालॉग्स

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

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

यदि आप पर्यावरण में ऊपर वर्णित अजीब प्रदर्शन के करीब सादृश्य पाते हैं तो यह थोड़ा आसान हो जाएगा:

1. एक महिला से पहले सुंदर पुरुष प्रेमालाप ... रसोई में घरेलू तसलीम
2. बाजार में आलू खरीदना
3. भाग्य बता रहा है, ज्योतिष, अंक ज्योतिष
4. चेतुलु, आदि के लिए बलिदान

यह स्पष्ट है कि यह अब तक आसान नहीं हुआ है, खासकर यदि आपको याद है कि प्रदर्शन में अक्सर दोनों पक्षों के "प्रमाणित मनोवैज्ञानिकों" द्वारा भाग लिया जाता है, जो आश्वस्त, निर्णायक, कह सकते हैं कि "हाँ, निश्चित रूप से हम करेंगे!" और सॉफ्टवेयर विकास के मूल सिद्धांतों को नहीं समझते हैं। और अगर आपको याद है कि कभी-कभी परियोजना के दोनों सिरों पर "आश्वस्त दिखने वाला" सामने की रेखा को पार कर जाता है, तो एक साथ एकजुट हो जाते हैं, और इंजीनियरों से कुछ ठोस मांग करने पर सीधे ईमानदारी से नाराज होने लगते हैं, बिना स्पष्ट रूप से सामने आए सवालों के स्पष्ट औपचारिक उत्तर दिए बिना ... मैं वास्तव में जाना चाहता हूं। अंटार्कटिका में अकादमिक अवकाश और पेंगुइन और ठंडे-पानी को गले लगाना भूल जाते हैं, लेकिन इससे कम सुंदर नहीं है, mermaids :-)

प्यार का धक्का

इंजीनियरों के लिए यह काफी दर्दनाक और विश्लेषणात्मक रूप से ऊपर वर्णित प्रदर्शन का अनुभव है, जब तक कि वे आंखों से खून नहीं बहाते हैं, इसलिए वे कई प्रसिद्ध मनोवैज्ञानिक कदम उठाते हैं जो ठोस और वास्तविक काम को करीब लाते हैं:

• एक-दूसरे को देखकर मुस्कुराने की जरूरत है
• मुझे हां कहना चाहिए, भले ही कोई विश्वास न हो
• एक-दूसरे की मदद करने का वादा करने की जरूरत है
• आपको अपनी छाती (जैसे किन्कॉन्ग) पर टैप करना होगा और आत्मविश्वास का प्रदर्शन करना होगा!
• कसम से प्यार हो जाएगा

लेकिन गंभीरता से बोलते हुए, इस स्तर पर, परियोजना टीम के सभी सदस्यों के बारे में बहुत स्पष्ट होने की आवश्यकता है:

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

कुल मिलाकर, प्रदर्शन के अंत में, अज्ञात भविष्य में एक निश्चित धक्का दिया जाना चाहिए, और एक दूसरे को सुनने और सुनने की एक अच्छी, जोरदार मनोदशा और आपसी इच्छा में।

स्टिलबोर्न प्रोजेक्ट्स

दुर्भाग्य से, कभी-कभी सचमुच तुरंत एक समझ होती है कि परियोजना शुरू की जा रही है ... किसी को भी इसकी आवश्यकता नहीं है, ट्विच, फ्रीज और संग्रह में फेंक दिया जाएगा:

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

प्रभावी प्रदर्शन प्रकार

यह संतुष्टिदायक है, लेकिन अक्सर, परियोजनाओं की सही शुरुआत सामने आती है, जिसे निम्नलिखित संकेतों से अलग किया जा सकता है। इस सूची में रहें और हुक या बदमाश द्वारा ऐसी टीमों में जाने का प्रयास करें:

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

लेकिन ध्यान रखें - इस तरह के एक प्रशिक्षित ग्राहक के साथ एक बैठक का मतलब होगा इंजीनियरिंग टीम के लिए वादा आईटी स्वर्ग, पसीना, श्रम और रक्त से वंश। डिज़ाइन पैटर्न के सभी ज्ञान से आप चौंक जाएंगे, बिना त्रुटियों के तुरंत सरल कोड लिखना सिखाया जाएगा, और 20 लाइनों के पीएचपी में स्क्रिप्ट का उपयोग करने के बजाय, आप क्लास फैक्ट्री को एक राक्षसी प्रलोभन के रूप में अस्वीकार कर देंगे। सुबह में, कॉफी डालने के बाद, आपको यह जानकर आश्चर्य होगा कि क्लाइंट, (बाद में!) आपके परीक्षण विभाग ने, बगट्रैकर में एक और 30-40 कीड़े पाए और पंजीकृत किए हैं और आपको सलाह देते हैं कि आप (आप!) सावधानीपूर्वक इकाई परीक्षण लिखें और परीक्षकों के मस्तिष्क को बदल दें। ... लेकिन दूसरी ओर, यह पंपिंग में अच्छा है :-)

तो आप एक सॉफ्टवेयर परियोजना का मूल्यांकन कैसे करते हैं?

मैं सीधे बोलूंगा। उचित लोग, सहित इंजीनियर समझते हैं कि अभी तक जो आविष्कार नहीं किया गया है उसका मूल्यांकन करना असंभव है ... कोई केवल आत्मविश्वास से झूठ बोल सकता है। लेकिन, जैसा कि आप जानते हैं, औपचारिक गणितीय तर्क हर किसी के लिए काम नहीं करता है, इसलिए कभी-कभी, फिर भी, आप ऐसे वार्ताकारों से मिलेंगे जो दावा करते हैं कि 1 + 1 = 11, और यह इतना आश्वस्त है कि आपकी आँखों में भी आँसू आ सकते हैं।

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

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

टीम की योग्यता के अनुरूप सादृश्य का उपयोग करना महत्वपूर्ण है:

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

कुछ इस तरह। हां, आप बहस कर सकते हैं, लेकिन पीएमबीओके, गैंट चार्ट, वेलिसिटी, कानबन कार्ड्स, मोटी एजाइल एस्टीमेशन बुक्स, टीम एक्सेलेरेशन, मेट्रिक्स, पेट्रीक के बारे में क्या कहेंगे? सच कहूँ तो, यह काम नहीं करता है और मैं "मशीन लर्निंग" के साथ एक सादृश्य बनाऊंगा।

मशीन सीखने और मूल्यांकन

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

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

ज्ञात गालियाँ

यह मज़ेदार है, लेकिन कभी-कभी रेटिंग की ऐसी गालियाँ सामने आती हैं जो अनुभवी इंजीनियरों को केवल मुस्कुराने का कारण बनाती हैं:

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

सॉफ्टवेयर परियोजनाओं में उपयोगी और कामकाजी मूल्यांकन प्रथाओं

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

• "सरल, मध्यम, कठिन।" हां, हम एक विशेषज्ञ डेवलपर या टीम के साथ परामर्श करते हैं और ProductBacklog में प्रत्येक सुविधा पर 3 की रेटिंग डालते हैं। परियोजना की सभी ज्ञात विशेषताओं के माध्यम से जाना और कम से कम इस तरह का मूल्यांकन देना उचित है। यह संभव है और आवश्यक है, केवल यह हाथ में है - पहले से ही रिलीज की योजना बनाने के लिए।
• "नियोजन पोकर।" इस विषय पर बहुत सारी जानकारी है, लेकिन यदि आप मूल्यांकन के दौरान आपके, टीम के सदस्यों और क्लाइंट के बीच संचार और विश्वास का एक स्वस्थ और सकारात्मक माहौल सुनिश्चित करते हैं, तो यह अच्छी तरह से काम करता है।
• "एक दोस्त को बुलाओ।" यदि आपके पास एक कंपनी / टीम है या एक परिचित विशेषज्ञ डेवलपर है, तो उससे बात करें। दुर्भाग्य से, कभी-कभी टीमें विश्वास करती हैं और समय बढ़ाने की कोशिश करती हैं - एक विशेषज्ञ कार्यान्वयन का पर्याप्त मूल्यांकन दे सकता है।
• सुविधाएँ और संचार अधिकतम रूप से देखे जाते हैं। अलग कॉर्क बोर्ड बाहर खड़े हैं, उन पर लटकाए गए सुविधाओं के साथ पत्रक, लोग ऊपर आते हैं, चर्चा करते हैं, अन्य बोर्डों को आकर्षित करते हैं, जो ध्यान में रखते हुए, सूखे फ्लैस्टर और एक काम करने वाले वॉशर नहीं हैं। यहाँ इस विषय पर एक महान संसाधन है ।

उपकरण और अच्छे अभ्यास अक्सर योजनाओं और समय सीमा से अधिक महत्वपूर्ण होते हैं।

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

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

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

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

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

कुल मिलाकर

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

सभी को शुभकामनाएं और अच्छे मूड!