तुम्ही विकिपीडियाबद्दल खरंच जाणता !

हा मूळ लेख http://techmr.wordpress.com वर अक्षय सावध यांनी लिहिला असून येथे प्रकाशित झाला आहे; येथे तो परवानगीने पुन:प्रकाशित केला आहे.

आजच्या जगात ज्ञान हेच धन आहे. आज ज्याच्या जवळ जास्त माहिती तो जास्त सुरक्षित आहे. त्याच मुळे आज ज्ञानाची किंमतही वाढली आहे. जसे की, कोणत्याही महाविद्यालयात प्रवेश घ्या किंवा कोणतेही पुस्तक घ्या, ते फ़ारच महाग झाले आहे. बरेचदा महागाईमुळे आपल्याला आपल्या ज्ञानाच्या भुकेला मुरड घालावी लागते.


जर हे सर्व ज्ञान मोफ़त उपलब्ध झाल्यास किती छान होईल. असाच विचार  ’जिमी वेल्स’ यांनी केला व त्यावर कृती सुध्दा केली. त्यातूनच Wikipedia चा जन्म झाला. ज्ञानाचे अपरिमीत भंडार लोकांसाठी खुले झाले, ते पण मोफ़त. आपल्या पेकी बरेच लोकांना याबद्दल माहीती असेल पण Wikipedia बरोबरच Wikimedia या समुहाचे अजुन अनेक प्रकल्प आहेत. ते सुध्दा अनेक भाषेतुन उपलब्ध आहेत. हे सर्व मराठीत सुध्दा उपलब्ध आहे. त्याच बद्दल आपण जाणून घेवू.

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

विकिपिडीया हा प्रकल्पाचा उद्दिष्ट जगातील सर्व भाषेत ज्ञानकोष तयार करणे हा होय. विकिपिडियाचा जन्म १ जानेवारि २००१ ला झाला. आता यात २७३ विविध भाषेत १ करोडच्या वर लेख आहे. यात सर्वात समोर इंगजी भाषा आहे. मराठीत आता ३२,२५६ विविध विषायावरिल लेख आहे व ते वाढत आहेत.
याच प्रमाणे विकिपिडियाचे अनेक प्रकल्प आहेत ते आपण एकेक करुन पाहू.

१. Wikipedia – मुक्त ज्ञानकोश

ह्या प्रकल्पात विविध विषयावर लेख लिहिले आहे. हे लेख मायाजाळावरिल स्वयंसेवक लिहितात. आपल्याला जर संगणक विषयी, नायजेरिया बद्दल किंवा भारताचा इतिहास जाणायचा असेल तर येथे सर्व उपलब्ध आहे. हि माहिती मराठीतही उपलब्ध आहे.
दुवा –  http://en.wikipedia.org
मराठी विकिपिडियाला भेट देण्यासाठी –  http://mr.wikipedia.org

२. Wiktionary – शब्दकोश

ह्या प्रकल्पात विविध भाषी मोफ़त शब्दकोश प्रत्येक भाषेत तयार करायचा आहे. याचा अर्थ एका भाषेचा उपयोग करुन सर्व भाषेतील सर्व शब्दाची व्याख्या करने. या प्रकल्पाची सुरुवात दिसेंबर २००२ ला झाली. आतापर्यंत यात १५० विविध भाषेत ३० लाख शब्द साठा आहे.दुवा – http://en.wiktionary.org
मराठीतील प्रकल्प  दुवा –  http://mr.wiktionary.org.

मराठीतील लेख लिहिण्यासाठी आपण मराठी विकिपिडियावर जावे व मराठीतील लेखांची संख्या वाढवावी.

३. Wikiquote  – अवतरणे

यात विविध प्रसिध्द लोकांचे, पुस्तकातील वा चित्रपटातील अवतरणे घेतली आहे. यात म्हणी , वाक्यप्रचार, घोषणा इ चा समावेश आहे. याची सुरुवात जुले २००३ मध्ये झाली. दुवा –  http://en.wikiquote.org/wiki/Main_Page
मराठीतील प्रकल्प दुवा –  http://mr.wikiquote.org

४. Wikibooks  – ग्रंथसंपदा

या प्रकल्पात मोफ़त इ-पुस्तके, विविध भाषा अभ्यासक्रम इ. चा साठा तयार करणे. याच मुख्य उद्देशः विद्यार्थाना व शिक्षाकांना स्वसाहायता व्हावी याकरीता. येथे  विविध पुस्तके मिळू शकतात.
याचा दुवा – http://en.wikibooks.org/

५. Wikisource – स्त्रोतपत्रे

हा विविध भाषेतील प्रकल्प नोव्हेंबर २००३ ला मोफ़त व उपलब्ध असलेले कागदे जमा करण्यासाठी सुरु झाला. यामुळे आता महत्वाचे अनेक कामे जसे की कोणत्याही देशाचे संविधान इ गोष्टी साठवून ठेवता येतात व त्याचे भाषांतर सुद्धा करता येते. यात आता पर्यंत ८.८ लाख विविध कागदे जमा झाली आहे. येथेच मला भारतीय संविधान भेटले.
याचा दुवा –  http://en.wikisource.org/

६.  Wikiversity  –  विद्यापीठ

हा प्रकल्प माहिती, शिकण्यारे समूह सोबतच संशोधन करण्यासाठी वाहिलेले आहे. याची सुरुवात १५ ऑगष्ट २००६ ला झाली.  हा फ़ार महत्व पुर्ण प्रकल्प आहे. हा फ़क्त विश्वविद्यालया संबधीतच नाही तर कोणत्याहि पातळीवरिल विद्यार्थास मदत होइल असे आहे. यात २०१० पर्यत ३०,००० प्रवेश आहेत.
याचा दुवा –  http://en.wikiversity.org/wiki/Wikiversity:Main_Page

७. Wikimedia Commons- सामायिक भंडार

या प्रकल्पात मोफ़त छायाचित्रे, नकाशे , व्हिडिओज, अ‍ॅनिमेशन इ चा समावेश आहे. याची सुरुवात सप्टेंबर २००४ ला झाली.
याचा दुवा –  http://commons.wikimedia.org/

८. Wikispecies  –  प्रजातीकोश

या प्रकल्पात विविध सजीव प्राण्यांबद्दल माहिती भेटेते. याची सुरुवार १४ सप्टेंबर २००४ ला झाली. हा प्रकल्प खास करुन वेज्ञानिक गोष्टी साठी आहे. यात २०१० पर्यंत २४ लाख लेख आहेत.
याचा दुवा –  http://species.wikimedia.org/

याच बरोबर खालील काही प्रकल्प आहे.

९. Wikinews – बातम्या

यात विविध बातम्या लिहिता येतात. याचे मुख्य काम म्हणजे बातमीची खात्री करणे व विश्वासह्रायता तपासणे हे होय.
दुवा –  http://en.wikinews.org/wiki/Main_Page

१०. Media Wiki

हे एक सॉफ़्ट्वेअर आहे. जे की सर्व Wikimedia समुह व इतर संकेतस्थळे वापरतात.
दुवा-  http://meta.wikimedia.org

याच प्रमाणे अनेक प्रकल्प wiki-  वा  -pedia या नावाने सुरु आहेत. पण वरिल १० प्रकल्प सोडुन कोणताही प्रकल्प  Wikimedia  या समूहाचा नाही. त्याच प्रमाणे Wikimedia वरिल सर्व माहिती वाचनासाठी व वापरण्यासाठी मोफ़त आहे.

याच वर्षी विकिपिडियाला १० वर्षे पुर्ण झाली. आता विकिपिडिया भारतातकडे खास लक्ष देणार आहे. त्यासाठी त्यांनी भारतीय भाषेचा प्रकल्प सुरु केला आहे.

आपल्याला हा लेख कसा वाटला ते कळवा. त्याच प्रमाणे अधिक माहिती असल्यास सर्वांसोबत वाटा.

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

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

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

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

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

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

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

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

स्क्रमचे cycle :

Scrum Cycle

वरील आकृतीत आपल्याला तीन roles दिसतील, Scrum Master ,Team आणि Product Owner. या roles बद्दल आपण मागल्या लेखामध्ये पाहिलं. आता इतर माहिती घेऊ.

Product Backlog :
आकृतीमध्ये “Product – Backlog” असं एक artifact (deliverable ) दाखवलेलं आहे. Product  Backlog म्हणजे Requirement document. या document मध्ये “Product” पूर्ण होण्यासाठी जी जी features करावी लागतील व जे जे  करावे लागेल ते सर्व दिलेले असते. हा “Product Backlog” product owner ने तयार करायचा असतो.सर्वसाधारण requirement document व “Product Backlog” यामध्ये एक महत्त्वाचा फरक म्हणजे Product Backlog मध्ये सर्व features / requirements या प्राधान्यक्रमाने दिलेल्या असतात. म्हणजे सर्वात जास्त अग्रक्रमाचे feature सर्वात वर व त्या खालोखाल कमी अग्रक्रमाची features मांडली जातात. प्रोजेक्ट चालू असताना जर हा अग्रक्रम बदलावा लागला (Business value प्रमाणे ) तर तसं करण्याचं काम Product owner करतो .

Sprint Planning Meeting :
तर असा हा product backlog , Product owner तयार करून Team पुढे ठेवतो. Team हा product backlog नीट समजून घेते. प्रत्येक feature ची Business value / priority समजून घेते. समजा एखाद्या product backlog मध्ये २५ गोष्टी प्राधान्यक्रमाने मांडल्या आहेत. साहजिकच या २५ गोष्टींमध्ये सगळ्यात वरच्या गोष्टी जास्त महत्त्वाच्या आहेत व त्या आधी develop करायला हव्यात. तर product owner , Scrum master आणि Team ही मंडळी एकत्र बसतात. आता या २५ गोष्टींपैकी किती गोष्टी आता सुरु होणार्‍या iteration मध्ये develop करायच्या याचा निर्णय team घेते. एरवी खरं तर हे project manager ने ठरवलं असत. पण इथे तसं नाही. team निर्णय घेते (Empowered team ). Team ने समजा असं ठरवलं की या iteration मध्ये (Scrum मध्ये iteration ला sprint म्हणतात ). पहिल्या पाच गोष्टी develop करायच्या तर त्या पाच गोष्टींसाठी कोणत्या tasks कराव्या लागतील त्याची यादी team तयार करते. या यादीतील tasks ची team आपापसांत वाटणी करते. ही tasks ची यादी Sprint Backlog मध्ये लिहिली जाते. असा Sprint Backlog तयार झाला की meeting संपते. या meeting ला Sprint Planning meeting असे म्हणतात.

स्प्रिंट:-
Sprint Planning Meeting नंतर Sprint (म्हणजेच iteration )सुरु होते. Sprint चा कालावधी साधारणपणे २ आठवडे ते ४ आठवडे असतो. Team ने Product owner ला commitment दिलेली असते की, २ ते ४ आठवड्यांच्या काळात team ठरलेल्या गोष्टी पूर्ण करून देईल. यासाठी team आपल्या कामाचा रोज आढावा घेते. हा आढावा दैनंदिन scrum meeting मध्ये घेतला जातो. (आता हे काय ? Scrum मध्ये ‘scrum meeting’?  होय , team च्या या रोजच्या meeting ला scrum किंवा daily Scrum म्हणतात.) Team मधील प्रत्येक जण इतर सर्वांना आपल्या कामाबद्दल माहिती देतो. (report करतो.) प्रत्येकजण तीन प्रश्नांची उत्तरे इतर सर्वाना देतो.
१. मी काल काय काम केलं?
२. मी आज काय काम करणार आहे ?
३. माझ्यासमोर काम करताना काय अडचणी आहेत ?
सर्वांनी ही माहिती दिल्याने team मधील प्रत्येकाला कामाची पूर्ण कल्पना येते. Meeting नंतर Sprint Backlog मध्ये झालेल्या कामाची नोंद केली जाते. म्हणजे किती तासांचं काम बाकी राहयाल आहे. हे शोधून काढलं जातं. हे खरंच किती logical वाटत ना! Project साठी किती काम झालं आहे यापेक्षा किती राहयाल आहे हेच महत्त्वाचं असतं. Sprint Backlog मधील राह्यलेल्या कामाच्या तासांची नोंद एका आलेखावरदेखील केली जाते; याला Sprint burn -down  chart म्हणतात.
अशाप्रकारे  प्रत्येक Sprint च्या सुरुवातीला Sprint Planning meeting व Sprint मध्ये दररोज ‘Daily Scrum meeting ‘ होते. Sprint Backlog हे प्रत्येक Sprint साठी input document असतं, व ते आणि burn – down chart पूर्ण sprint च्या काळात update केले जातात.
एक महत्त्वाचा नियम म्हणजे Sprint चालू असताना ठरलेल्या कामामध्ये कोणताही बदल केला जात नाही. Team ने ठरवलेल्या व Product Owner ने sprint च्या सुरुवातीला मान्य  केलेल्या गोष्टीच फक्त develop केल्या जातात. त्यामूळे Team ची एकाग्रता वाढून उत्पादन क्षमताही वाढते. Sprint च्या शेवटी काय होते, ते पुढच्या लेखात पाहू.

श्री. प्रशांत पुंड यांना येथे संपर्क करू शकता –
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

Localhost वर WordPress कार्यान्वित कसे कराल?

WordPress कार्यान्वित कसे कराल?

तुमच्या संगणकावर वर्डप्रेस कार्यान्वित करण्यासाठी संगणकावर WAMP सर्ह्वर असणे गरजेचे आहे. WAMP सर्ह्वर कसा कार्यान्वित करायचा ते तुह्मी् येथे पाहू शकता. या लेखात आपण wordpress कसे कार्यान्वित करायचे ते पाहू.

WordPress तुह्मी येथून डाउनलोड करू शकता.

१. तुह्मी डाउनलोड केलेली फाइल unzip करा.
२. वर्डप्रेस कार्यान्वित करण्यासाठी तुम्हाला तुमच्या वेब सर्ह्वरवर डेटाबेस तयार करावा लागतो. तो तुह्मी खाली दिल्याप्रमाणे तयार करू शकता.

->खालील चित्रात दाखवल्याप्रमाणे तुमच्या संगणकावरील WAMP सर्ह्वरच्या आयकॉनवर क्लिक करा व त्यावरील phpMyAdmin हा पर्याय निवडा.

-> खालील चित्रात दाखवल्याप्रमाणे तुह्माला हवे असलेले डेटाबेसचे नाव लिहा व Create या बटनावर क्लिक करा. अशाप्रकारे तुमचा डेटाबेस तयार होईल.

३. तुमच्या wordpress फोल्डरमधील wp-config-sample.php ह्या फाइलचे नाव wp-config.php असे बदला .

४. त्यानंतर wp -config.php ही फाइल text editor मध्ये उघडा व त्या फाइलमध्ये तुमच्या डेटाबेसचे details लिहा व ती फाइल जतन( save ) करा.

५. त्यानंतर तुमचा wordpress फोल्डर तुमच्या web server च्या root directory (C:\ WAMP \ www) मध्ये जतन करा.

६. तुमच्या web browser वर wp-admin/install.php run करा म्हणजे तुमच्या localhost वर wordpress कार्यान्वित होईल.

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

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

RSS feed आणि गुगल रीडर

RSS (Really Simple Syndication) हा वेबसाईट कडून अपडेट्स मिळवण्याचा एक format आहे. तुम्ही साईटच्या RSS feeds ला सबस्क्राइब केले की तुम्हाला प्रत्येक वेळी साईटवर जाऊन अपडेट्स बघण्याची गरज नाही. साईटवर जेंव्हा नवीन पोस्ट्स येतील तेंव्हा ते अपडेट्स तुम्हाला तुमच्या RSS feed reader मध्ये मिळतील.

जर तुम्ही इंटरनेट वापरत असाल आणि बरेच ब्लॉग्स, वेबसाईट्स वाचत असाल, तर त्या त्या साईटवर नवीन माहिती आली आहे की नाही हे बघण्यासाठी तुम्ही काय करता ?

साईट्स बुकमार्क्स करून प्रत्येक वेळी सर्व साईट्स उघडून बघणे हा एक पर्याय आहे. पण त्याचे बरेच तोटे आहेत. एका संगणकाच्या browser वर सेव्ह केलेले बुकमार्क्स तुम्हाला दुसऱ्या संगणकावर पाहता येत नाहीत. बरेचसे ब्लॉग्स अनियमितपणे अपडेट्स होतात. त्यामुळे एखादी साईट उघडल्यावर जुनीच पोस्ट दिसण्याचा प्रकार बरेचदा दिसतो. इंटरनेटचा स्पीड कमी असल्यास वेळ आणि bandwidth दोन्ही वाया जाते.

दुसरा पर्याय म्हणजे इमेलद्वारा सबस्क्रीप्शन. हा एका चांगला पर्याय असला तरी याचेही काही तोटे आहेत. एक म्हणजे तुम्ही वाचत असलेल्या सगळ्याच साईट्सवर हा पर्याय असतो असे नाही. आणि बरेचदा अश्या ठिकाणी मेलआयडी दिल्यावर स्पॅममेल्सच जास्त येण्याची शक्यता असते.

तिसरा पर्याय म्हणजे आर.एस.एस. फीड द्वारा अपडेट्स मिळवणे.

RSS (Really Simple Syndication) हा वेबसाईट कडून अपडेट्स मिळवण्याचा एक format आहे. तुम्ही साईटच्या RSS feeds ला सबस्क्राइब केले की तुम्हाला प्रत्येक वेळी साईटवर जाऊन अपडेट्स बघण्याची गरज नाही. साईटवर जेंव्हा नवीन पोस्ट्स येतील तेंव्हा ते अपडेट्स तुम्हाला तुमच्या RSS feed reader मध्ये मिळतील. RSS reader मधून तुम्ही सबस्क्राइब केलेल्या सर्व साईट्स चे अपडेट्स एकाच User interface मध्ये दिसतात. त्यामुळे एकाद्या ब्लॉगवरील फॉंट अथवा background कलर आवडत नसेल तरी काही फरक पडत नाही.

गुगल रीडर हि गुगलची RSS feed reader ची सर्व्हिस आहे. गुगल च्या account ने तुम्ही यावर लॉग-इन करू शकता. लॉग-इन केल्यावर डाव्या बाजूला असलेल्या “Add Subscription” मध्ये तुम्हाला हव्या असलेल्या साईटची URL टाकले की झाले. त्या साईटवर होणारे सगळे अपडेट्स तुम्हाला गुगर रीडर वर कळवण्यात येतील. गुगल रीडरवर नवीन फीड्स शोधण्याचीसुद्धा सोय आहे ज्याद्वारे तुम्ही तुमच्या आवडीच्या विषयाचे नवीन ब्लॉग्स, साईट्स शोधू शकता.

गुगल रीडर मध्ये नवीन साईट कधी Add करायची हे सांगणारा हा व्हीडीओ तुम्ही पाहू शकता.

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

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

जी-मेल मध्ये ई-मेल पाठविण्यासाठीच्या सुविधा

मागील भागात “जी-मेल मधे ई-मेल खाते कसे उघडावे?” या लेखानंतर, ई-मेल पाठविण्यासाठी कोणकोणत्या सुविधा उपलब्ध आहेत याविषयी माहिती देणारे हे चलचित्र: