---

परियोजना समझने से पहले पूरी योजना बनानी पड़ी? यह आपको चौंका सकता है!

स्क्रम के बिना हमारी टीमों ने ग्राहकों की माँग न पूरी करने वाले बिलकुल गलत सॉफ्टवेयर और हार्डवेयर दिए थे।

पेशेवर जीवन में तीसरी कंपनियाँ हम पर उत्पाद या सेवाएँ बनाने के तरीके थोपती थीं।

क्षमता परिपक्वता मॉडल (CMM), ISO 9001:2008 और अन्य रूपों ने सही सॉफ्टवेयर सही तरीके से बनवाने में मदद की कोशिश की।

वे कितने सफल रहे, यह पुस्तक का विषय नहीं। यह लगभग लुप्त प्रक्रियाओं की आलोचना के बजाय स्क्रम प्रक्रिया और लाभों पर केंद्रित है।

लेकिन जोड़ना होगा कि स्क्रम से पहले ये सुधार ढाँचे चरणबद्ध तरीका सुझाते थे, जिसे कहते थे वॉटरफॉल सॉफ्टवेयर इंजीनियरिंग मॉडल.

हर परियोजना आवश्यकता विश्लेषण से शुरू होती थी, ताकि ग्राहक की जरूरत और इच्छा समझें।

फिर डिजाइन, कार्यान्वयन, परीक्षण (सत्यापन) और उत्पादन परिवेश में रखरखाव करके जीवनचक्र के अंत तक पहुँचते थे।

लेकिन वास्तविकता ऐसी नहीं थी!

वॉटरफॉल पद्धति बनाम स्क्रम ढाँचा

परंपरागत वॉटरफ़ॉल सॉफ़्टवेयर विकास मॉडल के चरण

वॉटरफॉल के किसी चरण की अनपेक्षित देरी के अगले चरणों पर प्रतिकूल प्रभाव अनिवार्य थे।

अध्ययनों में जाँची गई विफल परियोजनाओं के 80% से अधिक में वॉटरफॉल उपयोग विफलता का मुख्य कारक था। लेकिन क्यों?

बाईं ओर दिखे अनुसार चरण सख्त क्रम में हैं। पिछला पूरा होने पर ही अगला शुरू होता है। वापस जाना अक्सर कठिन, महँगा, निराशाजनक और समय लेने वाला है।

समयसीमा शुरुआत में तय और रिलीज योग्य उत्पाद अंत में मिलता है। एक चरण देर हो तो बाकी भी देर होते हैं।

बचने के लिए प्रबंधक शुरुआत में सभी संभावनाएँ और आवश्यकताएँ अत्यधिक बारीकी से पूरी तय करने की कोशिश करते हैं। लेकिन शुरुआत में परिभाषा कठिन है और बहुत आवश्यकताएँ बदलती हैं या बदलनी चाहिए।

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

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

कोई समझदार व्यक्ति नहीं मानेगा कि परीक्षण से पहले विकास समाप्त हो गया। लेकिन दुर्भाग्य से वॉटरफॉल ऐसे ही चलता था।

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

स्क्रम से पहले ऐसा जीवन था। कुशल स्क्रम पेशेवरों के बिना सॉफ्टवेयर विभिन्न टीमों में आगे-पीछे भेजना काम को नौकरशाही वाला, जटिल और अनुत्पादक बनाता था.

और उत्पाद के साथ कर्मचारी मनोबल तथा संगठन के मिशन की प्रतिबद्धता भी पूरी तरह प्रभावित होती थी।