अजाईल मेथडॉलॉजी – भाग ४

ही लेखमालिका अतिथी लेखक श्री. प्रशांत पुंड खास टेक मराठीसाठी लिहित आहेत. प्रशांत हे सॉफ्टवेअर मेथडॉलॉजीज, SDLC या संदर्भात कन्सलटंट आणि मेंटर म्हणून काम करतात. आतापर्यंतच्या त्यांच्या २५ वर्षाच्या करीयरमधे त्यांनी अनेक कंपन्यांमधे एक्झिक्युटीव पदावर जबाबदारी पार पाडली आहे. आजवर त्यांनी ७५ हून अधिक कंपन्यांमधे ४०० हून अधिक ट्रेनिंग सेशन्स घेतली आहेत. सध्या अजाईलसॉफ्ट मेथडॉलॉजीज ही स्वत:ची कंपनी स्थापन करून CEO या पदावर कार्यरत आहेत. अजाईलसॉफ्ट मेथडॉलॉजीज ही कंपनी सॉफ्टवेअर मेथडॉलॉजीज, आय. टी. सिक्युरीटी, SDLC या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

या लेखमालेतील मागील लेख आपण येथे वाचू शकता-

अजाईल मेथडॉलॉजी – भाग १

अजाईल मेथडॉलॉजी – भाग २

अजाईल मेथडॉलॉजी – भाग ३

मागील लेखामधे आपण अजाईलच्या चार मूलभूत तत्वाविषयी जाणून घेतलं. ’अजाईल’ या नावाने ज्या मेथडॉलॉजीज प्रचलीत आहेत, त्या सर्वांमध्ये याच तत्वांचा वापर होतो. अजाईलबद्दल सुरूवातीला ज्याचा अधिक वापर झाला ती पद्धत म्हणजे Extreme Programing किंवा XP. (अर्थात याचा Windows XP शी काही संबंध नाही, हे सांगायला नकोच.) अजाईल मेथडॉलॉजीज मधल्या बहुतेक सर्व technical practices या XP मधूनच आलेल्या आहेत. तुम्हाला प्रश्न पडला असेल की, यात extreme काय आहे; कळेलच..

Extreme Programing (XP):

आपण पाहिलं की Waterfall model वापरून Software Development शिस्तबद्ध करता येते पण त्यात कोणतीही लवचिकता नसते. अशी लवचिकता आणण्यासाठी मग ‘Iterative Development’ ही कल्पना पुढे आली. एका Iteration मध्ये softwareचे एखादे फिचर (feature), एखादी use case तयार करणे व पुढच्या प्रत्येक iteration मध्ये त्यात भर घालत जाणे. XP मध्ये हीच कल्पना अगदी extreme (टोकापर्यंत) नेली आहे. अगदी अल्पकाळाच्या iteration मधून कमीत कमी पण उपयुक्तता मूल्य असणारं software तयार करणे म्हणजे Extreme Programing. हे जर प्रत्यक्षात यशस्वी करायचं असेल तर बरीच पथ्य पाळावी लागतात. XP मध्ये काही आचारपद्धती(practices) सांगितलेल्या आहेत. त्या जर पाळल्या तर आपण आपल्या ग्राहकाला सतत उपयुक्त ठरणारे software देऊ शकतो. थोडक्यात उदाहरण द्यायचं झालं तर log in या functionality बाबत ग्राहकाला उपयुक्तता तेव्हा पटेल जेव्हा ’log in’ या बटनावर क्लिक केल्यावर प्रत्यक्षात log in page दिसेल. log in बद्दल कितीही मोठं document लिहिलं तरी त्याची value काय आहे? XP मध्ये आपण softwareचे असे अनेक उपयुक्त तुकडे ग्राहकाला दाखवत रहातो, ज्यायोगे ग्राहकाला जे, जसं हवं आहे तसं सतत मिळत रहाण्याचा फायदा मिळतो. आता आपण XP च्या १२ आचारपद्धती किंवा १२ सुत्रांपैकी काही महत्वाची सुत्रे समजून घेऊ.

१. On-site customer (ग्राहक developerच्या बरोबर):

आपल्याला प्रत्येक वेळी थोडं थोडं पण उपयुक्त असं software ग्रहकाला द्यायचं आहे. म्हणजे आपल्याला सतत ग्राहकाकडून feedback पण घ्यायचा आहे. ग्राहकाकडून प्रत्येक छोट्या function बद्दल खात्री करून घ्यायची आहे. यावर सर्वोत्तम उपाय म्हणजे ग्राहकानं developer बरोबर हजर असणं. आधीच्या लेखात म्हटल्याप्रमाणे

Team = customer + developers.

तुम्ही म्हणाल, ग्राहक हे मान्य करील का? ग्राहकाचा फायदा असेल तर का नाही करणार? लक्षात ठेवा की या गोष्टी प्रत्यक्ष वापरून झालेल्या आहेत आणि on-site customer ही केवळ पुस्तकी कल्पना नसून प्रत्यक्षात अनेक वेळा, अनेक ठिकाणी वापरलेली आहे.

२.  Test-Driven Development:

थोडीशी विचित्र वाटेल अशी ही पद्धत आहे. नेहमी आपण code लिहीतो आणि तो टेस्ट करतो. Test-Driven Development मध्ये मात्र आपण test-case आधी लिहितो आणि मग test-case pass होण्यासाठी code लिहितो. थोडसं उलटं वाटतं पण त्यामुळे जेवढा पाहिजे तेवढाच आणि योग्य code लिहिला जातो.

३. Pair Programming

दोन programmer एकाच कोडवर काम करतात. (हे काय? म्हणजे double efforts!) म्हणजे एक programmer code लिहितो आणि दुसरा सतत review करीत  असतो . थोड्यावेळाने review करणारा code लिहायला (type करायला )लागतो आणि आधीचा लिहिणारा review करायला लागतो. यानं code मध्ये defects राहत नाहीत, असा अनुभव आहे. प्रथमदर्शनी जरी हे double effert चं काम वाटल तरी defect काढायला जो वेळ जातो, त्यापेक्षा हे परवडतं.

४.  Re-factoring

प्रत्येकवेळी जर थोडासा code तयार करणार असू तर तो सतत आधीच्या code शी integrate करायला हवा. शिवाय तो असा लिहायला हवा की नवीन code त्यामध्ये सहज टाकता येईल. म्हणजे आपला code कोणत्याही क्षणी flexible,  scalable असा पाहिजे. Refactoring म्हणजे code चं function (किंवा interface) न बदलता तो असा सोपा करणे की त्यात बदल सहजपणे सामावू शकतील. हे काम XP मध्ये अगदी सतत करावं लागतं.
या लेखात मी फक्त महत्त्वाच्या चार practices विषयी लिहीलं आहे. इतरही practices  खूप महत्त्वाच्या आहेत. जास्त माहिती हवी असल्यास वाचकांनी ‘Extreme Programming Explained‘ हे kent Beck चं पुस्तक अवश्य वाचावं.

XP Cycle

XP मध्ये Customer हा developers ना UserStory (सध्या आपण याचा अर्थ User ला हवी असलेली लहानशी functionality असा घेऊ) देतो. अशा अनेक User Stories त्याने लिहिलेल्या असतात. अनेक User Stories ची मिळून एक मोठी functionality होऊ शकते. एका short development cycle (iteration) मध्ये किती User stories develop करता येतील हे developers ठरवतात. User stories बरोबर त्यांच्या test cases देखील developers ना मिळतात. अशा user stories मग developers एकत्रपणे काम करून आणि वर उल्लेखलेली सूत्रे (practices) वापरून तयार करतात.
अशी अनेक cycles होतात, ज्या व्दारे software हे iterative व incremental मार्गाने दिले जाते. आपल्या लक्षात आलाच असेल की XP मध्ये documentation पेक्षा working software, Negotiation पेक्षा customer collaboration इत्यादी Agile च्या मूळ तत्त्वांचा वापर केलेला आहे.

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
Linked In: http://www.linkedin.com/pub/dir/Prashant/Pund/
Blog : http://pundprashant.wordpress.com/
E-mail: prashant.pund at agilesoft.in

अजाईल मेथडॉलॉजी – भाग ३

ही लेखमालिका अतिथी लेखक श्री. प्रशांत पुंड खास टेक मराठीसाठी लिहित आहेत. प्रशांत हे सॉफ्टवेअर मेथडॉलॉजीज, SDLC या संदर्भात कन्सलटंट आणि मेंटर म्हणून काम करतात. आतापर्यंतच्या त्यांच्या २५ वर्षाच्या करीयरमधे त्यांनी अनेक कंपन्यांमधे एक्झिक्युटीव पदावर जबाबदारी पार पाडली आहे. आजवर त्यांनी ७५ हून अधिक कंपन्यांमधे ४०० हून अधिक ट्रेनिंग सेशन्स घेतली आहेत. सध्या अजाईलसॉफ्ट मेथडॉलॉजीज ही स्वत:ची कंपनी स्थापन करून CEO या पदावर कार्यरत आहेत. अजाईलसॉफ्ट मेथडॉलॉजीज ही कंपनी सॉफ्टवेअर मेथडॉलॉजीज, आय. टी. सिक्युरीटी, SDLC या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

या लेखमालेतील मागील लेख आपण येथे वाचू शकता-

अजाईल मेथडॉलॉजी – भाग १

अजाईल मेथडॉलॉजी – भाग २

मागील लेखामधे आपण पाहिलं की सगळ्या अजाईल मेथडॉलॉजीजमधे जे सार्धम्य आहे ते Agile Manifesto मध्ये दिसते. त्याविषयी थोडी चर्चा करू.

१. प्रोसेस आणि टूल्स पेक्षा व्यक्ती व परस्पर संभाषण:
People or Process? हा अगदी “Chicken first or egg first?” सारखा प्रश्न आहे. अजाईल मध्ये दृष्टीकोन असा आहे की, Defined process पेक्षा लोकांची सोय व त्यांच्यातील सुसंवाद महत्वाचा. खरं तर अमुक एक प्रोसेस वापरली तर प्रोजेक्टमधे हमखास यश मिळेल, हे एक स्वप्नरंजन आहे. मुंबईतले डबेवाले कोणती प्रोसेस वापरतात? त्यातल्या किती जणांनी Management Clerics वाचले/ऐकले आहेत? त्यांच्यातील परस्पर संवाद हेच यशाचे गमक आहे. त्यामुळे व्यक्ती केंद्रस्थानी मानून व परस्पर संवादाचा योग्य उपयोग करून यश मिळवता येईल, असं अजाईलचं तत्व आहे. प्रोसेस हे साधन आहे साध्य नव्हे.

२. Comprehensive Documentation (दस्ताऐवज/ कागदपत्रे) पेक्षा व्यवस्थित चालणारे सॉफ्टवेअर

ग्राहकाला त्याच्या गुंतवणुकीचा परतावा कशातून मिळतो? चालणार्‍या software मधून की अगदी नेटकेपणाने केलेल्या documentation मधून? मग महत्व सहाजिकच software तयार करण्याच्या कृतीला द्यायला हवं. Documentation हे जरूरीपुरतं नक्की करावं; पण त्याच्या मागे लागू नये. कितीतरी  documentation हे असं केलं जातं ही पुन्हा त्याकडे खरं तर कुणी ढुंकुनही पाहत नाही. पण केवळ प्रोसेसमध्ये लिहीलयं म्हणून बळेच करावं लागतं. हे थांबवूया.

३. करार व तडजोड पेक्षा ग्राहकांशी सुसंवाद

प्रोजेक्ट मॅनेजरच्या प्रस्थापित, अपेक्षित गुणांमध्ये एक गुण असतो तो म्हणजे negotiating skill- ग्राहकाबरोबर negotiation करणे, software requirement असो किंवा schedule  बद्दल सवलत असो; ग्राहकाला आपलं म्हणणं मान्य करायला लावण्यात तर खरं कौशल्य लागतं! पण खरंच यातून काय साध्य होतं? ’ मी जिंकणार, तू हरणार’ यापेक्षा ’मीही जिंकणार, तुही जिंकणार’ हे तत्व योग्य नाही का? अजाईलच्या संकल्पनेनुसार ग्राहकांशी negotiation करण्यापेक्षा सुसंवाद साधणे महत्वाचे आहे.

Customer + Developers = Team

Customer म्हणजे ’ते’ आणि Developers म्हणजे ’आपण’ असं म्हणण्यापेक्षा ’आपण सगळे एक’ असं म्हणणं जास्त योग्य ठरतं. ग्राहकाचा development मध्ये सहभाग हे तत्व अजाईल मेथडॉलॉजीजने स्वीकारलं आहे.

४.  पक्की ठरविलेली योजना पाळणे (Defined Process) पेक्षा  बदलांना सामोरे जाणे

Software Development मध्ये बदल हीच शाश्वत गोष्ट आहे! Technologies बदलतात, requirements बदलतात, मार्केटमधल्या अपेक्षा बदलतात. Software Development मध्ये या सार्‍या बदलांना सामोरं जायचं असेल तर प्रोसेसमध्ये लवचिकता हवीच. त्यामुळे Rigid Process पेक्षा बदलांना सामोरं जाण्याची सहज क्षमता असणारी कार्यपद्धती महत्वाची ठरते.

वरील मूलभूत तत्त्वे आपल्याला Crystal, Extreme Programming, Scrum इत्यादि Agile Methodologies मध्ये दिसतात.

Crystal

Crystal ही Agile Methodology अ‍ॅलिस्टर कॉकबर्न याने मांडली. यामध्ये एक प्रमुख कल्पना अशी होती की कोणत्याही Methodology ला तीन dimensions असतात

१) Roles

2) Activities

3) Project Life Stage
ही dimensions जर x, y व z axis म्हणून धरली तर Methodology(M)  ची size ठरवता येते. जितके Roles किंवा Activities किंवा development stages जास्त, तितकी ‘ M ‘ size जास्त. या अनुशंगाने काही conclusion मांडता येतात.

१) जितके जास्त लोक (प्रोजेक्ट्वर काम करणारे) तेवढी M size जास्त लागते. (जास्त लोक असतील तर formal communication लागेल)

२) प्रोजेक्टमध्ये जोखीम (risk ) जास्त असेल तर M size जास्त हवी  (उदा. Pacemaker तयार करायचा असेल तर M size जास्त,  Cricket Score software ला M size कमी )

यामुळे  Crystal Clear,  Crystal Red,  Crystal Yellow,  Crystal Orange अशी वेगवेगळी versions (Team size नुसार) मांडली गेली. याव्यतिरिक्त Team ला focus गरजेचा असतो, बाहेरील लोकांनी Team members ना disturb करू नये,  समोरासमोर (face to face ) संभाषण हे सर्वात प्रभावी असते इत्यादि अजाईलच्या प्रमुख कल्पना Crystal मध्ये होत्या.  Crystal विषयी अधिक जाणून घेण्यासाठी अ‍ॅलिस्टर कॉकबर्नचे Crystal विषयावरील पुस्तक अवश्य वाचावे.
पुढील लेखात आपण Extreme Programming (XP) बद्दल चर्चा करू .

पुढील लेख:

अजाईल मेथडॉलॉजी – भाग ४

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
Linked In: http://www.linkedin.com/pub/dir/Prashant/Pund/
Blog : http://pundprashant.wordpress.com/
E-mail: prashant.pund at agilesoft.in


अजाईल मेथडॉलॉजी – भाग २

ही लेखमालिका अतिथी लेखक श्री. प्रशांत पुंड खास टेक मराठीसाठी लिहित आहेत. प्रशांत हे सॉफ्टवेअर मेथडॉलॉजीज, SDLC या संदर्भात कन्सलटंट आणि मेंटर म्हणून काम करतात.  आतापर्यंतच्या त्यांच्या २५ वर्षाच्या करीयरमधे  त्यांनी अनेक कंपन्यांमधे एक्झिक्युटीव पदावर जबाबदारी पार पाडली आहे. आजवर  त्यांनी ७५ हून अधिक कंपन्यांमधे ४०० हून अधिक ट्रेनिंग सेशन्स घेतली आहेत. सध्या अजाईलसॉफ्ट  मेथडॉलॉजीज ही स्वत:ची कंपनी  स्थापन करून CEO या पदावर कार्यरत आहेत. अजाईलसॉफ्ट  मेथडॉलॉजीज ही कंपनी सॉफ्टवेअर मेथडॉलॉजीज, आय. टी. सिक्युरीटी, SDLC या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

मागील लेखामधे आपण मेथडॉलॉजीज या संक्ल्पनेविषयी चर्चा केली. वॉटरफॉल व त्यानंतर आलेल्या Iterative Methodologies बद्दल जाणून घेतलं. प्रस्तुत लेखात आपण अजाईल मेथडॉलॉजीज बद्दल आणखी माहिती घेऊ.

बदलाची गरज
Defined Process मुळे Software Industry मध्ये एक सुसुत्रता आली, हे खरे. Process manual असल्यामुळे कशा क्रमाने काम करायचे, तसेच सर्व प्रोजेक्ट्सची माहिती शास्त्रीय पद्धतीने गोळा करणे, त्याचे विश्लेषण (analysis) करणे व त्यानुसार प्रोसेसमध्ये आवश्यक ते बदल करणे शक्य झाले. या फायद्यांमुळेच CMMI level 2 पासून 5 पर्यंत क्रमाक्रमाने प्रगल्भता (maturity) मिळविण्याकडे कंपन्यांचा कल वाढला. Quality process मध्ये CMMI व्यतिरीक्त ISO, TQM, Six Sigma अशा इतरही अनेक process frameworks/ standards ची चलती वाढली.
“अति सर्वत्र वर्जयेत” या उक्तीनुसार जेव्हा प्रोसेसचा बाऊ केला जातो, तेव्हा मागील लेखात म्हटल्याप्रमाणे “Process for people” की “People for process” हा संभ्रम होतो.
Process standardization चा सगळ्यात महत्वाचा फायदा म्हणजे त्यायोगे येणारी शिस्त अन या शिस्तिचा अतिरेक म्हणजे लवचिकता संपुष्टात येणे, हीच अडचण समोर येऊ लागली.
अजाईल या संकल्पनेकडे एखादे फॅड किंवा फॅशन म्हणून बघणे Software Industry ला नक्कीच परवडणारे नाही. खरा प्रश्न आहे तो, खरेच काही बदल हवा आहे का, याचा. Defined process वापरत असताना बदलांना सामोरे जाण्याची क्षमता कमी झालेली आहे किंवा ते बदल सामावून घेण्याची किंमत वाढली आहे, ही पहाणे गरजेचे आहे.

अजाईल जाहीरनामा (Agile Manifesto)
काही मेथडॉलॉजीस्ट मंडळींना एकत्र येऊन “अजाईल मेथडॉलॉजीज” ही संकल्पना मांडली. एकत्र येण्याआधी स्वतंत्रपणे त्यांनी “एक्स्ट्रिम प्रोग्रॅमिंग“(Extreme Programming ), “क्रिस्टल” (Crystal) यांसारख्या मेथडॉलॉजीज विकसित केलेल्या होत्या. एकत्र आल्यावर यातील सार्धम्य लक्षात घेऊन त्यांनी अजाईल जाहीरनामा (Agile Manifesto) ठरविला; तो असा-
आम्ही सॉफ्टवेअर तयार करण्याच्या अधिक चांगल्या पद्धती शोधीत आहोत आणि त्याबाबत इतरांनाही मदत करीत आहोत. हे करत असताना खालील गोष्टींना प्राधान्य द्यावे, असे आमच्या लक्षात आले आहे.

“प्रोसेस आणि टूल्स”                               पेक्षा                      “व्यक्ती व परस्पर संभाषण”

“दस्ताऐवज/ कागदपत्रे”                            पेक्षा                      “व्यवस्थित चालणारे सॉफ्टवेअर”

“करार व तडजोड”                                  पेक्षा                      “ग्राहकांशी सुसंवाद”

“पक्की ठरविलेली योजना पाळणे”                 पेक्षा                     “बदलांना सामोरे जाणे”

वर डावीकडे दिलेल्या गोष्टी महत्वाच्या आहेतच पण आम्ही उजवीकडच्या गोष्टींना  जास्त प्राधान्य देतो.

(स्वैर भाषांतर – “Agile Manifesto” हक्क agilemanifesto.org च्या स्वाधीन)

वर दिलेल्या चारही तत्वांचे प्रतिबिंब आपल्याला प्रत्येक अजाईल मेथडॉलॉजीजमध्ये दिसेल.

थोडक्यात ही तत्वे पाळणारी कोणतीही मेथडॉलॉजी असेल (अगदी तुम्ही स्वत: ठरविलेली) त्याला अजाईल मेथडॉलॉजी म्हणता येते. सध्या अस्तित्वात असलेल्या काही अजाईल मेथडॉलॉजीज खालीलप्रमाणे आहेत-

१. एक्स्ट्रिम प्रोग्रॅमिंग (XP)

२. स्क्रम (Scrum)

३.  लीन डेव्हलपमेंट (Lean Development)

४. डी. एस. डी. म (DSDM)

५. ऍडाप्टिव सॉ्फ्टवेअर डेव्हलपमेंट (Adaptive Software Development)

६. फीचर ड्रीव्हन डेव्हलपमेंट (Feature Driven Development)  इत्यादी.

“अजाईल” च्या चार तत्वांविषयी व आणखी काही तत्वांविषयी जाणून घेऊ पुढील लेखात.

अजाईल मेथडॉलॉजी – भाग ३

अजाईल मेथडॉलॉजी – भाग ४

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
Linked In: http://www.linkedin.com/pub/dir/Prashant/Pund/
Blog : http://pundprashant.wordpress.com/
E-mail: prashant.pund at agilesoft.in

अजाईल मेथडॉलॉजी – भाग १

ही लेखमालिका अतिथी लेखक श्री. प्रशांत पुंड खास टेक मराठीसाठी लिहित आहेत. प्रशांत हे सॉफ्टवेअर मेथडॉलॉजीज, SDLC या संदर्भात कन्सलटंट आणि मेंटर म्हणून काम करतात.  आतापर्यंतच्या त्यांच्या २५ वर्षाच्या करीयरमधे  त्यांनी अनेक कंपन्यांमधे एक्झिक्युटीव पदावर जबाबदारी पार पाडली आहे. आजवर  त्यांनी ७५ हून अधिक कंपन्यांमधे ४०० हून अधिक ट्रेनिंग सेशन्स घेतली आहेत. सध्या अजाईलसॉफ्ट  मेथडॉलॉजीज ही स्वत:ची कंपनी  स्थापन करून CEO या पदावर कार्यरत आहेत. अजाईलसॉफ्ट  मेथडॉलॉजीज ही कंपनी सॉफ्टवेअर मेथडॉलॉजीज, आय. टी. सिक्युरीटी, SDLC या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

सध्या “अजाईल” हा शब्द अगदी परवलीचा झाला आहे. बर्‍याच कंपन्यांमधे अजाईल मेथडॉलॉजी वापरली जाते. हे नेमकं काय आहे याचा मागोवा या लेखमालेत आपण घेणार आहोत.

मेथडॉलॉजी म्हणजे नेमकं काय?

बर्‍याच वेळेला आपल्याला मेथड (Method), प्रोसेस(Process) आणि मेथडॉलॉजी (Methodology) असे वेगवेगळे शब्द दिसतात. खर्‍या अर्थाने या शब्दांमधल्या फरकांबाबत एक स्वतंत्र लेख लिहिता येईल. सध्या तरी आपण फारसा शैक्षणिक किंवा तात्विक विचार न करता आपल्याला उपयोगी पडेल असा मेथडॉलॉजीचा अर्थ पाहू.

सॉफ्टवेअर तयार करताना डिझाईन, कोडिंग, टेस्टींग अशा अनेक क्रिया कराव्या लागतात. या क्रिया कोणत्या क्रमाने, कोणी व कशा करायच्या याचे ढोबळमानाने वर्णन केले तर ते वर्णन म्हणजे मेथडॉलॉजी होय. अर्थात मी आधी म्हटल्याप्रमाणे ही काही शास्त्रीय व्याख्या नाही.

तर मेथडॉलॉजीमधे खालील तीन घटकांचा संबंध येतो.

१. भूमिका (Role)

2. क्रिया (Activity)

3. क्रियेत वापरले जाणारे किंवा क्रियेतून निर्माण होणारे आर्टिफॅक्ट्स(Artifacts)

या तीन घटकांचा परस्पर संबंध सुनिश्चित करणे म्हणजे मेथडॉलॉजी.

१९७० च्या सुमारास विन्स्टन रॉईस यांनी एका पेपरमधे Waterfall Model ची कल्पना मांडली. खरं तर त्या पेपरचा उद्देश Waterfall Model सुचविण्याचा नव्हता. पण तरीही Waterfall Model वापरण्याची सुरूवात झाली. Analysis -> Design-> Coding-> Testing या क्रमाने सॉफ्टवेअर तयार करायला सुरूवात झाली. सॉफ्टवेअर कंपन्यांनी या Waterfall Methodology वर आधारीत प्रोसेस (Process) तयार केल्या. पुढे पुढे यामधे लोकांना त्रुटी जाणवू लागल्या. मोठ्या मोठ्या प्रोजेक्ट्ससाठी ही मेथडॉलॉजी फारशी उपयुक्त नसल्याचे जाणवले. जवळजवळ एका दशकाच्या काळानंतर (विन्स्टन रॉईसच्या पेपर्नंतर) डॉ. बॅरी बोहमच्या Spiral Model ने आणि आणखी काही तत्कालीन मॉडेल्सने मेथडॉलॉजीबाबत वेगळे विचार मांडले. पुढे आयव्हर जेकबसनच्या Objectory आणि नंतर Unified Process ने Waterfall Model आधारीत वेगळ्या मेथडॉलॉजीज मांडल्या.

या इतर सगळ्या मेथडॉलॉजीजमध्ये एक साम्य होतं, ते म्हणजे Waterfall Model चा पुन्हा पुन्हा वापर. यालाच आपण iterative model म्हणू. थोड्या काळासाठी (iteration) Waterfall वापरणे, त्यातून सॉफ्टवेअरचा काही भाग तयार करणे, पुन्हा आणखी थोडा भाग तयार करण्यासाठी Waterfall वापरणे. असं केल्याने एकूण प्रक्रियेतील जोखीम कमी होते, असं जाणवलं होतं.

मेथडॉलॉजीज आणि प्रोसेस यांचा परस्पर संबंध कंपन्यांमध्ये तयार झाला होता. Process Manual मध्ये कुणी, केव्हा, काय करायचं याचे नियमच लिहून ठेवले जाऊ लागले; मग ती मेथडॉलॉजी Waterfall असो किंवा आणखी कुठली. हळू हळू या प्रोसेस, क्वालिटी प्रोसेस म्हणून ओळखल्या जाऊ लागल्या. CMMI आणि ISO Model ने सॉफ्टवेअर कंपन्यांचा ताबा घेतला. ज्याची प्रोसेस चांगली त्याचे प्रोडक्ट चांगले असा विचार पुढे आला. जो तो आपली प्रोसेस अधिकाधिक घट्ट व कोणत्याही चुकीला वाव नसावा अशा बेताने ठरवू लागला. कंपनीतील काम करणारे डेव्हलपर्स, टेस्टर्स हे एखाद्या यंत्राप्रमाणे प्रोग्रॅम केल्यासारखे ही प्रोसेस पाळू लागले, किंबहूना तेच अपेक्षित होते.

कधी कधी तर माणसांसाठी प्रोसेस की प्रोसेससाठी माणसं, असा प्रश्न निर्माण होऊ लागला. या मेथडॉलॉजी आणि प्रोसेसच्या चक्राकडे काही लोक मात्र अभ्यासूपणे पाहत होते आणि नवनविन प्रयोग करीत होते. केंट बीक, ऍलिस्टर लॉकबर्न, केन श्वॉबर, जेफ सदरलॅंड  इ. लोकांनी वेगवेगळ्या मेथडॉलॉजीज मांडल्या. प्रोसेसमध्ये लवचिकता यावी, असा आग्रह धरला. या मेथडॉलॉजीज, लाईटवेट मेथडॉलॉजीज म्हणून ओळखल्या जाऊ लागल्या; ज्यांनाच पुढे अजाईल मेथडॉलॉजीज असं नाव पडलं.

पुढील लेखात आपण या अजाईल मेथडॉलॉजीजच्या मूल तत्वांविषयी जाणून घेऊ.

अजाईल मेथडॉलॉजी – भाग २

अजाईल मेथडॉलॉजी – भाग ३

अजाईल मेथडॉलॉजी – भाग ४

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
Linked In: http://www.linkedin.com/pub/dir/Prashant/Pund/
Blog : http://pundprashant.wordpress.com/
E-mail: prashant.pund at agilesoft.in