टेक मराठी महामेळाव्याबद्दल अहवाल

टेक मराठी महामेळाव्याबद्दल अहवाल, टेक मराठी महामेळाव्यामधील प्रतियोगी श्री. राम गद्रे यांनी आम्हाला पाठविला. तो वाचकांसाठी जसाच्या तसा खाली देत आहे.

***  टेक मराठी महामेळावा ***
गद्रे परिवारातील सायली गद्रे कडून फेसबुकवर टेक मराठीचा महामेळावा दिनांक ७ व ८ जानेवारी २०१२ या दोन दिवशी असल्याचे समजले.या मेळाव्यास उपस्थित रहाण्याचे आमंत्रणच तिने दिले होते.या संबधीची थोडी माहितीपण तिने कळविली होती.हा मेळावा संगणकासंबधी असल्याचे लक्षात आल्यावर या मेळाव्यात भाग घेण्यासाठी अप्पा बळवंत चौकात रसिक साहित्य मध्ये पैसे भरून नोंदणी केली.आणि शनिवारी ७ जानेवारीला मॉडेल कॉलनीतील Symbiosis Institute of Computer Studies & Research मध्ये गेलो. तेथे सायली गद्रेची भेट झाली.रजिस्ट्रेशन झाल्यावर साधारण सकाळी साडेदहाचे सुमारास श्री.प्रकाश पुंड यांनी उपस्थितांचे व प्रमुख पाहुण्यांचे स्वागत केले.प्रमुख पाहुण्यांचे हस्ते दीप प्रज्वलन झाल्यावर
महा-मेळाव्याच्या कार्यक्रमाला सुरवात झाली. प्रमुख पाहुणे श्री.पानसरे यांनी उद्घाटनाचे भाषण केले.सध्याच्या युगात कॉप्यूटर म्हणजेच संगणकाला किती महत्व आहे आणि त्यात इंजिनियरिंग व इतर अनेक टेक्निकल विषय शिकतांना किंवा आत्मसात करतांना मराठीतून ते शिकणे किंवा शिकवणे गरजेचं झालं आहे.सामान्य लोकांना किंवा ज्येष्ठ नागरिकांना (ज्यांचा आतापर्यंत कॉंप्युटरशी फारसा संबंध आलेला नाही त्यांना) मराठीतून टेक्नॉलॉजी समजावी.अर्थात्‌ यावेळी इंग्रजीचा तिरस्कार न करता म्हणजेच प्रत्येकवेळी अगदी अबोध आणि बोजड मराठी प्रतिशब्दच न वापरता रुळलेले इंग्रजी शब्द वापरून मराठीतून उत्तम संवाद साधण्याचा प्रयत्न ही टेक-मराठी चळवळ करणार आहे किंवा करेल असे विचार मुख्य पाहुण्यांनी मांडले.मातृभाषेतून उत्तम संवाद सांधण्यासाठी व मराठी भाषेविषयी प्रेम व्यक्त करण्यासाठी हा महामेळावा आयोजित करण्यात आल्याचे प्रकाश पुंड यांनी सांगितले.उद्घाटनाचा कार्यक्रम उत्तम प्रकारे झाल्यावर उपस्थित participants अर्थात सहभागी श्रोत्यांचे दोन गट करण्यात आले,नवोदित आणि जाणकार असे.नवोदितांसाठी कॉप्यूटर विषयी प्राथमिक माहितीचा वर्ड,एक्सेल,पॉवरपॉईंट,इंटरनेट इत्यादी संबधीचा एक वर्ग आणि थोड्या माहिगारांसाठी दुसरा.यामाहितगारां -साठीच्या वर्गात श्री.अनिल परांजपे यांनी facebook व twitterविषयी माहिती दिली.Twitterसंबधीचांगली माहिती मिळाली.बरेच अभिनेते,राजकारणी या ट्विटरवर मत मांडतात,लिहितात असे समजले.यावर फक्त १४० characters पर्यंतच म्हणजे साधारण २ ओळी किंवा वाक्यच लिहिता येतात. असे समजले.सर्व वर्तमानपत्रांच्या ठळक बातम्या यावर पहाता येतात.त्या पेपरांच्या वेगवेगळ्या साईट्सवर जाण्याची गरज नाही.latest news पहाता येतात.येथे सतत updates होतात.त्यामुळे कोणतीही बातमी लवकर समजते.यावर अगदी कोणत्याही क्षेत्राची माहिती मिळू शकते.या सर्व चांगल्या गोष्टींमुळे परांजपे ट्विटरचा जास्त वापर करतात असे त्यांनी सांगितलं.Twitter ची वैशिठ्ये आणि त्याची उपयोगिता पहाता फेसबुक पेक्षा ट्विटर वापरणे अधिक सोयीस्कर असे लक्षात आले.हा वर्ग सम्पल्यावर थोडा वेळ नवोदितांच्या वर्गात गेलो.तेथे पल्लवी कदडी इंटरनेट संबधी माहिती देत होत्या,बऱ्याच शंका विचारल्या जात होत्या आणि त्या योग्य प्रकारे निरसन पण केल्या जात होत्या.ज्यांची मुले बाहेरगावी किंवा परदेशात आहेत त्यांना याचा नक्कीच उपयोग होणार आहे.मेल मध्ये मजकूर जरी मराठीत लिहून पाठविण्याची सोय असली तरी e-mail i.d.इंग्रजीतच लिहावा लागतो.(हा मजकूर लिहीत असतांना आज दि.१८ जानेवारी २०१२ च्या सकाळ मध्ये एक बातमी वाचली त्याप्रमाणे,वेबसाईट पहातांना संकेतस्थळांचे पत्ते आता मराठीतही लिहिणे शक्य होणार असल्याचे दिसून आले.जसे,www.e-sakal.comऐवजी आता www.ईसकाळ.भारत असे लिहिणे शक्य होणार आहे.सी-डॅक मध्ये झालेल्या संशोधनामुळे हे शक्य झाले आहे.आता या पुढची पायरी म्हणजे ई-मेल आय-डी मराठीत लिहून मेल पाठविता येईल अशी आशा करायला हरकत नाही.) जेवणानंतरच्या सत्रात ब्लॉग बनविणे,संकेतस्थळे वगैरेची माहिती मिळाली.
रविवार दि.८ जानेवारीला सकाळी पहिल्या सत्रात श्री.प्रसाद शिरगावकर यांनी मराठी वेबसाईट कशी तयार करायची या संबधी वर्ग घेतला.

याची प्राथमिक माहिती,डोमेन नेम,जावा,HTM,वेब सर्व्हर वगैरेची माहिती सांगितली.वेबसाईट तयार करण्याचा हेतू ( objective ),ती कोणासाठी बनवायची (Target Audience ),काय माहिती सांगायची,त्यातीलसाहित्य,वेबसाईटच्या मालकां बरोबर संपर्क कसा साधायचा,ही वेब साईटकायम स्वरुपी कि बदलती ( Static/Dynamic )ठेवायची,त्यात फोटो किंवा लेख टाकायचे कां इत्यादि गोष्टींचे पूर्ण नियोजन करूनच बेब साईट बनविणे चांगले व सोपे जाते आणि ती पूर्ण effective होते.या सत्रात उपस्थित असलेल्या सर्वांच्या वेबसाईट बनविण्याचा प्रयत्न होता.पण त्या लॅबमध्ये एकाचवेळी ५०/६० जण हजर असल्यामुळे इंटरनेट कनेक्शन मिळणे खूप वेळखाऊ होते.कनेक्शन लवकर मिळत नव्हते.त्यामुळे सर्वांच्या वेबसाईटस बनू शकल्या नाहीत.शिरगावकर सर मात्र “मिळेल,मिळेल,जरा सबुरीने”,असे गमतीचे आश्वासन देत होते.सर्वांनी घरी गेल्यावर वेबसाईट बनविण्याचा प्रयत्न करावा असे त्यांनी सांगितले.तसेच परत कधी तरी हा क्लास शक्य होईल तेथे घेऊ आणि राहिलेल्या गोष्टी पूर्ण करू असे त्यांनी सांगितले.बघुया परत कधी जमते ते.घरी प्रयत्न करायला हरकत नाही.( आजच्या म्हणजे १८ जानेवारी च्या महाराष्ट्र टाईम्स वर मटा सजेशन
मध्ये आकर्षक वेबसाईट बनविण्यासाठी एक साईट दिली आहे.ती म्हणजे,www.tiptopwebsite.com
आणि त्यात विविध टिप्स देण्यात आल्या आहेत असे वाचनात आले.जमेल त्यांनी त्यावरून प्रयत्न करावा.
फक्त ही साईट मराठीत आहे किंवा कसे माहीत नाही.)वेब साईट बनविता आली नाही तरी जेवणाची सुट्टी मात्र घ्यावीच लागली.
जेवणानंतरमराठी विकिपेडिया हा  विषय होता आणि वक्ते होते,मंदार  कुलकर्णी आणि “ माहितगार”  म्हणजे,विजय सरदेशपांडे.या  वर्तुळात ते माहितगार म्हणूनच  प्रसिद्ध आहेत.मंदार कुलकर्णी यांनी  प्रथम मराठी विकिपेडिया संबधी  प्राथमिक माहिती सांगितली.या  मराठी विकिपीडियाची स्थापना १ मी  २००३ रोजी झाली.हा जणू एक  विश्वकोशचआहे.अनेक गोष्टींची आणि  विषयांची माहिती यावरून उपलब्ध होते.यावर नवीन लेख तयार करता येतात,असलेल्या लेखांमध्ये भर घालता येते किंवा त्यात बदल करता येतो.त्यात काही चुका असल्या तर त्या दुरुस्त करता येतात.इंग्रजीतील चांगले लेख मराठीत अनुवादित करता येतात.या सर्व गोष्टी समजल्यावर खूप आनंद झाला.आता या साईटचा आपल्याला चांगला उपयोग करून घेता येईल.यानंतर सरदेशपांडे सरांनी मराठी विकिपिडीयाचा प्रत्यक्ष वापर करण्यासाठी काही उपयोगी टिप्स दिल्या.ई-सकाळ वरून एखादी बातमी निवडून-कि ज्यावर लेख वगैरे मराठी विकिपीडिया वर आलेला नाही ते चेक करून-दोघा,तिघांनी मिळून लेख तयार करण्यास सांगितले होते.पण बरेच जण नेटवरून त्या साईटवर प्रयत्न करीत होते त्यामुळे ती साईट मिळत नव्हती किंवा काहीतरी प्रॅाब्लेम येत होता त्यामुळे माहिती गोळा करून लेख तयार करणे पूर्ण होऊ शकले नाही.अखेर वेळ संपत आल्यामुळे प्रत्येकाने घरी जावून प्रयत्न करावा असे सांगण्यात आले .बघुया कधी जमते ते,काही जणांनी नक्कीच प्रयत्न केला असेल.निदान मराठी विकिपीडिया वरून आवश्यक असेल तेंव्हा माहिती मिळवून आपल्या ज्ञानात भर नक्कीच घालता येईल.माहितगार व त्यांच्या टीमचे आभार मानल्यावर तो तास संपला.
आता या सेमिनारचे शेवटचे सेशन होते,श्री.अतुल कहाते यांचे.त्यांनी मराठीत संगणक,मराठी टायपिंग या बाबतचे स्वत:चे अनुभव शेअर केले.एखादी कथा किंवा लेख आधी हाताने लिहून मग तो प्रकाशनासाठी पाठविणे यात खूपच वेळ जातो त्यापेक्षा जर कॉम्प्युटरवर मराठीत लिहिता आले तर सवयीने ते जलदगतीने करता येते,टायपिंग करत असतांना किंवा नंतर त्यात फार त्रास न घेता सुधारणा करता येते,
कागद फुकट जात नाहीत,लिहिलेले सेव्ह करून वेळ मिळेल तेंव्हा परत पुढे लिहिता येते.इंग्रजीतील चांगले साहित्य मराठी अनुवादित करण्यासाठी खूप स्कोप आहे..संगणकावरमराठी टायपिंग करण्याची स्फूर्ती त्यांनी विजय तेंडुलकर यांचे कडून घेतल्याचे सांगितले.विजय तेंडुलकर दिवसा बराच वेळ बसून आपल्या लॅपटॉपवरमराठी लिहीत असत असं त्यांनी सांगितलं.आपणपण आता संगणकावर चांगले मराठी लिहू या.
त्यांचे, सर्व उपस्थितांचे,सहकार्यांचे व सिंबायोसिस इन्स्टिट्यूटचे आभार मानून हा सेमिनार संपला.
प्रमुख पाहुणे- अतुल कहाते

टेक मराठीचे स्वयंसेवक-ओंकार, प्रशांत,निखिल, सिध्दार्थ,चैतन्य, गौरी,सायली, पल्लवी..

उत्साही श्रोते

—राम गद्रे.

मराठी विकिपीडिया संपादन – अवघड की सोपे?

सदर लेख श्री. मंदार कुलकर्णी यांनी लिहीला आहे. हा लेख सकाळ आवृत्तीत प्रकाशीत झाला होता. ते येथे पुन:प्रकाशीत करण्यात येत आहे.

 

विकिपीडिया
विकिपीडिया

इंटरनेटने अवघे जग अगदी कमी कालावधीमध्ये व्यापून टाकले आणि तो आपल्या जीवनचा एक अविभाज्य भाग झाला आहे. आज जगातली कोणतीही ताजी बातमी, ताजी घटना या सर्वात पहिल्यांदा इंटरनेट उपलब्ध होतात. ज्यांना विशिष्ट वेबसाइट ची माहिती हवी असते ते साहजिकच गुगल किंवा तत्सम सर्च इंजिन वर जातात. तर ज्या मंडळींना ज्ञान आणि माहिती हवी आहे ते विकिपीडियाचा वापर करतात. इंग्रजी विकिपीडियाच्या सर्च मध्ये कुठलाही शब्द टाकला की त्या संदर्भात संपूर्ण माहिती इंग्रजी विकिपीडिया वर उपलब्ध होते. याचे कारण आज इंग्रजी विकिपीडिया मध्ये जवळजवळ ३८ लाख लेख आहेत.

“मराठी विकिपीडिया” यात मागे नाही. २००३ च्या महाराष्ट्र दिनी “मराठी विकिपीडिया” ची सुरुवात झाली. मराठी जाणणारे अनेकजण यास सक्रीय हातभार लावत आहेत. “वसंत पंचमी” हा पहिला ज्ञात लेख मराठी विकिपीडियावर तयार झाला. विकिपीडियाच्या मराठी अवतारात सध्या ३४८६८ लेख उपलब्ध करण्यात आले असून एकूण संपादनाची संख्या ९ लाखाच्या जवळपास आहे. मराठी विकिपीडिया मध्ये एकूण पानांची संख्या ९४००० असून एकूण सभासद १९६०० पेक्षा जास्त आहेत॰ येथे सध्या १३२ नियमित सदस्य असून अखंड कार्यरत आहेत. दिवसाचे २४ तास जगभरातून यामध्ये भर घालणे चालू आहे. हे सर्व सदस्य नियमितपणे या वेबसाइटसाठी काम करीत आहेत.

मराठी विकिपीडियाचा प्रचालक म्हणून अभ्यास करील असताना असे लक्षात आले की देवनागरी लिपीमध्ये लिहिताना सामान्य जणांना येणार्‍या अडचणी या मराठी विकिपीडिया ला सध्या मारक ठरीत आहेत. इंग्रजी ही जगाची भाषा असल्याने आजकाल प्रत्येकाला इंग्रजी मध्ये टाइप करता येते पण त्याच सहजतेने मराठी मध्ये टाइप करणे अथवा लिहिणे बहूसंख्य लोकांना जमत नाही. अशा वेळेस साहजिकच जे सोपे आहे त्याकडे धावण्याचा कल असल्याने मराठी पेक्षा इंग्रजीकडे धावण्याचा मोह सर्वांना होतो. आज बहुसंख्य मंडळींना मराठी विकिपीडिया माहिती आहे आणि ते मराठी विकिपीडिया फक्त माहिती पहाण्यासाठी भेट देतात पण या ज्ञान कोशात भर घालणे ही तितकेच महत्वाचे आहे. आज मराठी मध्ये असंख्य वेब साइट्स, ब्लॉग्स लिहिले जातात पण त्यातल्या बर्‍याच लेखकांना त्यात भर कशी घालायची याचे फारसे ज्ञान नसते. एमेल सुद्धा जवळ जवळ सर्वच जण देवनागरी च्या ऐवजी रोमन मधेच लिहिणे जास्त पसंत करतात. आज सगळे संगणक रोमन लिपीचा की बोर्ड वर देत असल्याने देवनागरी संगणकावर लिहिणे हे असंख्य जणांना अवघड गोष्ट आहे. अनेक जण या बाबतीत नाराजी व्यक्त करतात. अगदी गुगल च्या सर्च इंजिनवरही मराठी शब्द शोधणे ही सोपी गोष्ट नाही. मराठी टायपिंग म्हणजे कटकट अशी अनेकांची धारणा असते. त्यामुळे साहजिकच अनेक मराठी मंडळी मराठी विकिपीडिया पासून किंवा मराठी विकिपीडियाच्या संपादन पासून वंचित राहतात.

या सर्व अडचणी विचारात घेता मराठी विकिपीडिया मधील काही संपादकांनी विविध पर्याय लेखकांना देण्याचा प्रयत्न केला आहे. मराठी विकिपीडिया वर एक देवनागरी फॉन्ट दिलेला आहे. हा उनिकोड फॉन्ट असून वापरायला अतिशत सोपा आहे. मराठी विकिपीडियाच्या कुठल्याही पानावर उजव्या कोपर्‍यात “देवनागरी” अशी अक्षरे असून त्याच्या शेजारी एक छोटी चौकट आहे. त्या चौकटीत ‘टिक’ केले की मराठी विकिपीडियावर आपण देवनागरी मध्ये लिहायला सुरुवात करू शकतो.

काही जणांना हा देवनागरी फॉन्ट वापरणे काहीसे अवघड जात असेल तर त्यांनी निराश व्हायचे काहीच कारण नाही. त्यासाठी इंटरनेट च्या जाळ्यात अनेक सोयी आहेत. त्या अशा:

  1. गूगल ने मराठी ट्रान्सलेटरेशन टुल तयार केले आहे. http://www.google.com/transliterate या मध्ये रोमन मध्ये लिहिलेला शब्द स्पेस बार दाबल्यावर देवनागरी लिपीमध्ये रूपांतरित होतो. या मध्ये काही ओळी लिहून त्या कॉपी करून मराठी विकिपीडिया वर तक्ता येऊ शकतात.
  2. तामिळ क्यूब ने एक उनिकोड कन्व्हर्टर तयार केला असून ही सुविधा मराठी लेखांसाठी उपयोगी पडू शकते. http://www.tamilcube.com/translate/marathi.aspx
  3. क्वीलपॅड या वेब साईट मध्ये भारतातील विविध भाषांमध्ये लिखाण करायची सुविधा दिली आहे. http://www.quillpad.in/marathi/. त्यामध्ये मराठी भाषा निवडून देवनागरी मध्ये लिखाण करता येते.
  4. ज्यांना देवनागरी लिपीमधील लिखाण एका ठिकाणी लिहून दुसरीकडे कॉपी करणे अवघड जात असेल त्यांच्यासाठी अजून एक झकास सोय ‘एपिक’ नावाचा एका भारतीय ब्रौझर मध्ये आहे. http://www.epicbrowser.com/ . यात 12 भारतीय भाषांसह एकूण 20 जागतिक भाषांमध्ये कोणत्याही इंटरनेटवरील खिडकीमध्ये लिहायची सोय आहे. हा ब्रौझर एकदाच आपल्या संगणकावर उतरवून घेतल्यावर आपल्याला हवे असलेले कोणतेही पान त्या ब्रौझर मध्ये उघडायचे आणि ज्या खिडकी मध्ये आपल्याला लिहायचे आहे तेथे गेल्यावर त्या खिडकीच्या उजवीकडील वरील कोपर्‍यात भाषांचा पर्याय येतो. तेथे मराठी भाषा निवडून त्या मुख्य खिडकीत सरळ लिहीत सुटायचे. प्रत्येक रोमन लिपीतील शब्दाचे देवनागरी मध्ये आपसूक भाषांतर केले जाते. जिथे एका रोमन शब्दाचे अनेक देवनागरी शब्द होऊ शकतात तेथे तसे पर्याय पाहायला मिळतात.
  5. आता अनेक लेखक असे म्हणू शकतील की वरील सर्व पर्यायांना इंटरनेट असणे किंवा संगणकावर इंटरनेट चालू राहणे आवश्यक आहे. जर काही मंडळींना आधी माहिती पूर्ण लिहून मगच मराठी विकिपीडियावर भरायची असेल तर त्यांच्यासाठी मायक्रोसोफ्ट ने एक सुंदर सोय केली आहे. http://specials.msn.co.in/ilit/Marathi.aspx या वेबसाइट वरून काही माहिती आपल्या संगणकात उतरवून घ्यायची आणि संगणकात कंट्रोल पॅनल मधील ‘भाषा’ मध्ये काही छोटेसे बादल केले तर संगणकाच्या लँग्वेज बार मध्ये मराठी भाषा येऊन बसेल. ती भाषा निवडली की अगदी सहज पाने वर्ड, एक्सेल, पॉवर पॉइंट मध्ये कोठेही कसेही लिखाण करता येईल. हे लिखाण करण्यासाठी इंटरनेटची आवश्यकता नाही. तसेच जिथे एका रोमन शब्दाचे अनेक देवनागरी शब्द होऊ शकतात तेथे तसे पर्याय पाहायला आहेतच.

तात्पर्य, देवनागरी लिहिणे हे आता अगदी सोपे झाले आहे. मराठी विकिपीडिया मध्ये भर घालण्यासाठी आणि मराठी विकिपीडिया उतरोत्तर वाढवण्यासाठी ज्या अडचणी येतात त्यावर विकिपीडिया ची तांत्रिक मंडळी अहोरात्र काम करीत असतात.

दिनांक १८ ते २० नोव्हे. २०११ या काळात मुंबई येथे “WikiConference India 2011” भरवली जात आहे. या सम्मेलनात ‘मराठी विकिपीडिया’ हा अतिशय प्राधान्याने घेतला गेला आहे. यात मराठी भाषेतून काही भाषणे आणि चर्चासत्र आयोजित केली असून महाराष्ट्रातील नव्हे तर जगभरून मराठी भाषिक आणि अन्य भाषिक येथे येणार आहेत. त्याचप्रमाणे मुख्य संमेलनात मराठी विकिपीडिया बरोबरच अन्य भारतीय भाषां संदर्भात माहितीची देवाणघेवाण आणि चर्चा आयोजली आहे.

मराठी विकिपीडिया पाहण्यासाठी http://mr.wikipedia.org  वर भेट द्या आणि मराठी विकिपीडिया मध्ये आपण सारे आपल्याकडे असलेल्या ज्ञानाची भर घालूया.

मराठी विकिपीडियाची संक्षिप्त आकडेवारी:

अजाईल मेथडॉलॉजी -भाग ७

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

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

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

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

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

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

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

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

स्क्रममधील स्प्रिंटबद्दल चर्चा केल्यानंतर आता प्रत्येक स्प्रिंटच्या शेवटी काय घडतं ते पाहू.

स्क्रम ही iterative आणि incremental पद्धत असल्यामुळे प्रत्येक स्प्रिंटच्या शेवटी Product owner किंवा customer ला अभिप्रेत असलेली business value मिळणं अपेक्षित असतं. ही business value त्या स्प्रिंटमधे काम करून तयार केलेल्या product increment द्वारा दाखविली जाते. Product ownerआणि इतर सहभागी घटक(stakeholder) यांना हे product increment दाखविण्याचा कार्यक्रम म्हणजे Sprint review meeting!

स्प्रिंट रिव्ह्यु मिटींग:

मुख्य उद्देश हा product increment कशा प्रकारे चालतं हे दाखविणे व त्यावर प्रतिक्रिया घेणे, हा असतो. सर्व stakeholders या मिटींगमधे सहभागी होतात.  पण power point slides, भाषणबाजी, हारतुरे यांना यामधे मज्जाव असतो.

“या स्प्रिंटमधे आम्ही हे develop केलं आहे, ते असं चालतं” हे demonstrate करण्याचं काम टीम  करते. यावर stakeholders प्रतिक्रिया देतात. काही features मधे बदल करणे Business value नुसार मान्य करण्याजोगे असेल तर product owner असे बदल Product backlog मध्ये प्राधान्यक्रमानुसार करतो.

स्प्रिंट रिट्रोस्पेक्टिव्ह:

स्प्रिंट रिव्ह्यू झाल्यानंतर product owner, scrum master आणि team असा ’आतला’ गट झालेल्या स्प्रिंटची पडताळणी करण्यास बसतो. याला स्प्रिंट रिट्रोस्पेक्टिव्ह असे म्हणतात. आपण कोणत्या गोष्टी योग्य प्रकारे करतो आहोत, कोणत्या गोष्टींमध्ये सकारात्मक बदल अपेक्षित आहेत, याचा उहापोह येथे केला जातो. प्रत्येकाने यामध्ये स्वत:चे मत नोंदविणे, सुचना करणे अपेक्षित असते. पुढच्या स्प्रिंटमध्ये, सदर सूचनांपैकी कोणत्या अमलांत आणायच्या, हेदेखील ठरते. याची अंमलबजावणी खरोखरच नंतरच्या स्प्रिंटमध्ये होईल, ही जबाबदारी Scrum Master वर असते.

स्प्रिंट रिट्रोस्पेक्टिव्ह बरोबरच sprint cycle संपतं आणि मंडळी पुढच्या स्प्रिंटच्या sprint planning meeting साठी तयार होतात.

आपण पाह्यलं की स्र्कममध्ये फक्त तीन roles आहेत. तसेच sprint planning meeting, daily scrum, sprint review आणि sprint retrospective अशा activities किंवा ceremonies आहेत. Product backlog, Sprint backlog, Burndown chart अशा artifacts आहेत. या सर्वांनी मिळून बनलेलं हे एक framework आहे. Development activities कशा करायच्या याबद्दल काहीही दिलेलं नाही. यामुळे बर्‍याच वेळा test driven development, re-factoring, user’s stories अशा Extreme Programming च्या कल्पना येथे वापरल्या जातात. Framework implementation मध्ये Engineering practices किंवा development techniques यामध्ये वैविध्य असू शकतं. पण Scrum च्या मूळ गाभ्याला धक्का लागणार नाही याची काळजी घेतली तर फायदा होतो.

या लेखमालेत ’अजाईल मेथडॉलॉजी’ ही काय भानगड आहे, याचं उत्तर संक्षिप्त स्वरूपात देण्याचा प्रयत्न केला आहे. या विषयांवर  बरेच साहित्य उपलब्ध आहे; त्याचा वाचकांनी जरूर लाभ घ्यावा.

ही लेखामाला ’अजाईल मेथडॉलॉजी’ या विषयाचीओळख करून देणारी  आहे. याविषयी आणखी लेख हवे असल्यास / काही प्रश्न असल्यास आपण खाली comments मध्ये जरूर लिहावे.

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
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 या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

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

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

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

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

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

मागील लेखामध्ये आपण XP या मेथडॉलॉजीतल्या काही महत्त्वाच्या तत्त्वांविषयी चर्चा केली. या लेखामध्ये आपण स्क्रम (Scrum ) या मेथडॉलॉजीविषयी पाहू.
स्क्रम (scrum)
स्क्रम हा कशाचाही short form नाही. हा शब्द रग्बी या खेळातून घेतला आहे , स्क्रमचे एका वाक्यात वर्णन करायचं झालं तर स्क्रम एक Agile Project Management Framework आहे. ज्याप्रमाणे आपल्या Architecture Framework मध्ये काही गोष्टी static (ठरलेल्या) असतात व काही भाग प्रत्येक application नुसार बदलतो, त्याचप्रमाणे या Agile Project Management Framework मधील काही भाग ठरलेला आहे व काही भाग त्या त्या Project /Product / Team / Environment नुसार ठरवण्याचा आहे. उदा. स्क्रममध्ये तीन role दिलेले आहेत; तसंच काही प्रकारच्या meetings ठरलेल्या आहेत. हा static part झाला. परंतु कोणत्याही engineering practices यामध्ये ठरलेल्या नाहीत. XP मध्ये सांगितलेल्या Engineering practices (TDD  , Refactoring वगैरे ) स्क्रममध्ये वापरता येणं शक्य असलं तरी त्या स्क्रमचा भाग नाहीत. म्हणून आपण ढोबळ मानाने याला Agile Project Management Framework म्हणू.
Project Management Framework मध्ये आपल्याला PMI , PRINCE2 वगैरे frameworks माहीत आहेत . ही Frameworks , waterfall किंवा Linear Development शी संलग्न आहेत. Agile सारख्या Iterative आणि Incremental development साठी मात्र स्क्रमसारखं वेगळं framework गरजेचं आहे.
आता आपण स्क्रम बद्दल एक Project Management Framework या दृष्टीकोनातून माहिती घेऊ . कोणतंही Project Management Framework हे who, When, how, where याबद्दल definition देते , त्याप्रमाणे स्क्रम मध्ये सुद्धा Roles , Activities आणि Artifacts दिलेले आहेत.
स्क्रममधील  Roles –
१. स्क्रम मास्टर (Scrum Master ) :
सर्वसाधारण Project मॅनेजरचा role स्क्रममध्ये स्क्रम मास्टर करतो. अर्थात Scrum Master आणि Project Manager यामध्ये बराच फरक आहे. पण आपण इतकं म्हणू शकतो की, scrum master हा Development team चा leader असतो. त्याचं काम Boss चं नसून Mentor किंवा Guide चं आहे. तो team ला बाहेरील disturbances पासून वाचवतो. तो team ची productivity जास्तीत जास्त राहण्यासाठी वातावरण निर्मिती करतो. Agile ची मुलभूत तत्त्वे पाळली जावीत, यासाठी आग्रही असतो.
२. Team :
Traditional Project Management मध्ये (Waterfall Model ) Analyst चं काम झाल्यावर Designers काम करतात , मग हे design developers / programmers ना दिलं जातं , त्यानंतर tester वगैरे . स्क्रम मध्ये ही सगळी मंडळी एकत्र येतात, एकत्र बसतात, एकत्र काम करतात. अशा team ला Cross – Functional Team म्हणतात. दुसरं म्हणजे ही team फक्त ७ +/- २ (५ ते ९ च्या दरम्यान ) इतकी लहान असते. तुह्मी म्हणाल, मोठं project फक्त ५ ते ९ लोकं develop करणार? तसं नाही, size नुसार कदाचित आपल्याला अशा अनेक लहान teams लागतील आणि त्यांच्यात काम वाटून द्यावं लागेल. आणखी एक महत्त्वाचा मुद्दा म्हणजे ही team स्वतःचे निर्णय स्वतः घेते, म्हणजे एका iteration मध्ये (ज्याला स्क्रम मध्ये स्प्रिंट Sprint म्हणतात ) किती functionality develop करायची हे team ठरवते. project च्या यशासाठी जे काही करावे लागते ते सर्व करण्यासाठी जिद्द आणि अधिकार team कडे असतात.
३. Product Owner :
आपण मागील एका लेखामध्ये पाहिलं होतं की Agile Methodology मध्ये ग्राहक (Customer ) प्रत्यक्ष सहभाग घेतो. जर functionalities एकामागोमाग एक develop करायची असेल तर काय आधी व काय नंतर हे ठरवलं पाहिजे. हे कुणी ठरवायचं? जर software develop करण्याचा उद्देश त्यापासून Business value / Returns मिळवणे असेल (नव्हे, तो तसंच असायला हवा ) तर आधी-नंतर हे Business value वर ठरवलं पाहिजे. मग Business value कुणाला नीट समजते? अर्थात Customer ला. स्क्रममध्ये Product Owner हा Customer चं प्रतिनिधित्व करतो. त्याला Business value नीट माहीत असते. तो सर्व functionalities ची प्राधान्यक्रमाने यादी करतो. त्यातूनच team आपलं काम निवडते. ही यादी सतत  प्राधान्यक्रमाने राहील याची काळजी घेण्याची जबाबदारी product owner ची असते.
प्रस्तुत लेखात आपण scrum मध्ये कोणते roles आहेत, हे पाहिलं पण ही मंडळी एकत्रितपणे project कस execute करतात , हे पुढील लेखात पाहू.

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
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 या संदर्भात ट्रेनिंग व कन्सलटन्सी या सेवा पुरविते.

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

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

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

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

मागील लेखामधे आपण अजाईलच्या चार मूलभूत तत्वाविषयी जाणून घेतलं. ’अजाईल’ या नावाने ज्या मेथडॉलॉजीज प्रचलीत आहेत, त्या सर्वांमध्ये याच तत्वांचा वापर होतो. अजाईलबद्दल सुरूवातीला ज्याचा अधिक वापर झाला ती पद्धत म्हणजे 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

रोहन दिघे या तरूण उद्योजगाचा प्रवास

रोहन दिघे ह्या २६ वर्षीय तरूणाने ३ वर्षापूर्वी “सोशल वेब फॅक्टरी” नावाची सोशल मिडीया ऍप्लिकेशन बनवीणारी सर्व्हिसेस कंपनी सुरू केली व नावारूपाला आणली. मेहनत व जिद्द यांनी युक्त असा हा त्याचा प्रवास त्याचाचकडून ऐकण्याची बहूमोल संधी POCC ने उपलब्ध करून दिली आहे.

रोहन दिघे ह्या २६ वर्षीय तरूणाने ३ वर्षापूर्वी “सोशल वेब फॅक्टरी” नावाची सोशल मिडीया ऍप्लिकेशन  बनवीणारी सर्व्हिसेस कंपनी सुरू केली व नावारूपाला आणली. मेहनत व जिद्द यांनी युक्त असा हा त्याचा प्रवास त्याचाचकडून ऐकण्याची बहूमोल संधी POCC ने उपलब्ध करून दिली आहे.

या वाटचालीमधे आलेले चढ-उतार, एका सर्व्हिसेस कंपनीपासून सुरुवात करून स्वत:च्या कंपनीचे प्रोडक्ट “डील तडका” जे नुकतेच बाजारात आले, हे करतानाचे अनुभव, भविष्याबद्दल दृष्टीकोन ह्या सर्वांबद्दल रोहन आपल्याशी बोलेल.

ही प्रेरणादायक गोष्ट ऐकायला आवर्जून या.

वेळ: दि. ७ मे २०११, दु. ४ ते सायं. ७

स्थळ: Symbiosis Institute Of Comp. Studies & Research(SICSR), अतुर सेंटर, गोखले क्रॉस रोड, मॉडेल कॉलनी, पुणे.

Google Map: http://bit.ly/93USLP

** ही सभा सर्वांना विनामूल्य आहे. आपली नोंदणी http://punestartups.org/events/rohan-dighes-my-story-pocc येथे करणे आवश्यक आहे.