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

ही लेखमालिका अतिथी लेखक श्री. प्रशांत पुंड खास टेक मराठीसाठी लिहित आहेत. प्रशांत हे सॉफ्टवेअर मेथडॉलॉजीज, 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


One thought on “अजाईल मेथडॉलॉजी – भाग ३

  1. Great article, easy to understood and simple language.
    This will help me in my testing and quality process.
    Thanks a lot.

Leave a comment

Your email address will not be published. Required fields are marked *

Enable Google Transliteration.(To type in English, press Ctrl+g)