स्मार्ट सिटी साठी सिस्टीम्स् थिंकिंग

[टेक मराठी दिवाळी अंकातील लेख आता टेक मराठी वेब साईटवर देखील प्रकाशीत होतील. यातील आजचा लेख
“स्मार्ट सिटी साठी सिस्टीम्स् थिंकिंग” -प्रशांत मिरजकर.]

 

” certification committee”  पैकी एक जण मंचावर येऊन बोलू लागला… कधी नव्हे ते प्रत्येकजण लक्षपूर्वक ऐकत होता….

प्रमाणपत्रात “नापास” हा शेरा पाहून सगळे चांगलेच वैतागले होते.४० जणांच्या गटामधे एकाच प्रमाणपत्रावर अभ्यासक्रम यशस्वीपणे पूर्ण केल्याचं शिक्कामोर्तब, ही संपूर्ण गट आणि कंपनीसाठीही मोठीच नाचक्कीची आणि संतापाची बाब होती आणि म्हणूनच ” certification committee”  ला पाचारण करण्यात आले होते. वक्ता बोलत होता….

”  systems thinking ” , प्रणालिबद्ध व्यवस्थेची मानसिकता यावर आपण ३ महिने तांत्रिक शिक्षण घेतलं आणि तुम्ही सर्वच जण आम्हांला प्रभावीपणे ते वापराल अशी खात्री वाटत होती.  “system thinking ”  ह्या विषयाचा हरेक पैलू या गटाला इत्यंभूत कळला आहे अशी आमची शिक्षक म्हणून धारणा होती.परंतु तसं अजिबातच नसल्याचं परिक्षांच्या दरमन्यान आमच्या लक्षात आलं. नाही … मला साक्षर , निरक्षर हा वाद घालायचा नाहीये… साक्षर तुम्ही जरूर आहात पण ”  systems thinking ”  च्या बाबतीत तुम्ही सुशिक्षित होऊ शकला नाहीत म्हणून हा निकाल. “मेक इन इंडिया / डिजिटल इंडिया” हे आपलं स्वप्न असेल तर वैयक्तिक दृष्ट्या   “systems thinking ”  च्या तत्वांचा वापर आपण कसा करू शकू याचं उत्तर “हे तर प्रशासन, सरकार, अधिकारी, यंत्रणा, व्यवस्था यांचं काम आहे” हे मिळणं म्हणजे आम्हाला आमचाच पराभव वाटू लागला… म्हणून खरं तर हा सगळा उहापोह… आज एक व्यक्ती म्हणून परत एकदा आपण सगळ्या गोष्टिंचा थोडक्यात विचार करू आणि इथे सगळेच  IT  मधून असल्याने तिथून सुरू करू…. एखाद्या कामात चूक ( bug)  सापडते म्हणजे नक्की काय होतं तर रचनेमधल्या एक किंवा अधिक गोष्टी अपेक्षित काम अपेक्षित पद्धतीने किंवा ठराविक वेळेत करत नाहीत. मग आपण रचनेचा आराखडा, त्याची अंमलबजावणी या सगळ्या गोष्टींचा विचार छोट्या छोट्या भागांपुरता आणि शेवटी सामाईकपणे पूर्ण यंत्रणा म्हणून करून ही चूक सुधारतो. आता या  IT  मधल्या प्रणालीचा रोजच्या आयुष्यात काय संबंध असा प्रश्न सगळ्या चेहऱ्यांवर दिसतो आहे; तर असा विचार करा की आपण आपली गाडी घेऊन फिरायला निघतो , माहित नसलेलं एखादं ठिकाण बघायला…. अशा वेळी आजकाल आपला सगळ्यात जवळचा वाटणारा मित्र किंवा राजू गाईड म्हणू आपण कोण असेल तर  GPS Tracker;  हा राजू गाईड आपण थांबलो की थांबतो, आपण पळू लागलो की पळतो आणि नुसता पळत नाही तर अजून बाकी असलेलं अंतर, आपल्या वेगानुसार तिथे पोहोचायला लागणारा वेळ, ही सगळी माहिती विनासायास पुरवत राहतो… पण विनासायास आपल्याला… हे सगळं बिनबोभाट घडतं कारण आपला मोबाईल किंवा गाडीमधला  GPS Tracker  , लाखो किलोमिटर दूर वसलेला उपग्रह, या दोन्हीला जोडणारे दुवे आपापलं काम नेमक्या वेळात, ठरलेल्या पद्धतीने, अथकपणे करतात म्हणून… यापैकी कुणीही समन्वयाचे भान सोडले की आपलं “जाते थे जापान पोहोंच गये चीन” असं काहीतरी व्हायचं… असंच काहीसं आपल्याला आनंद देणाऱ्या सगळ्या सुविधा ,  infrastructure, social media  यांचही…. सगळं कसं छान आहे.. प्रत्येक ”  system”  सतत माझ्या सेवेला हजर आहे

पण तरीही रोजच्या ट्रॅफिक ने वैताग येतोच, प्रदूषणाने छातीची आणि भ्रष्टाचाराने डोक्याची चाळण होतेच, पाण्याची बोंब आणि शेतात हरवलेले कोंब, प्रत्येक सरकारी कामात एजंट नाहीतर येरझाऱ्याचं बालंट, शिक्षणाच्या नावाखाली पोरांचे हाल आणि  AC में बैठके भी झडते हुए बाल :) … पण माझं काय संबंध नाही का या सगळ्याशी? मी काय करणार यात…. या सगळ्याचा त्या  bug concept  शी काय संबंध?

तर डोळे आणि डोकं पूर्ण उघडे ठेवून रोजच्या ”  systems  चा विचार करुया आणि त्यापेक्षा महत्वाचे म्हणजे मी या  systems  चा कसा अविभाज्य घटक आहे याचा… ट्रॅफिक चा रोजचा विषय घेऊया… स्मार्ट ट्रॅफिक लाईट सिस्टीम आहे… पोलिसांची फौज तैनात आहेत… खड्डे असले तरी बऱ्यापैकी पक्के रस्ते आहेत…लेन ची शिस्त परिभाषित आहे… रेडिऒ ठराविक वेळाने शहरातले “ट्रॅफिक अपडेट” देत आहे… जवळ जवळ सगळ्या मुख्य रस्त्यांवर समांतर वाहनतळ व्यवस्था आहे… प्रत्येक रस्त्याची वेगमर्यादा नमूद केलेली आहे; एकेरी वाहतूक कुठे ,दुहेरी कुठे … सायकल मार्ग, पदपथ सगळं निश्चित आहे… तरीही रोज ट्रॅफिक सुरळीत नाही! मग ह्या  systems  मधे एवढे  bug  आले कुठून… कोणता घटक , कोणता दुवा गहाळ झालाय? याचं उत्तर ”  systems thinking ”  ची तत्वं वापरून शोधायचा प्रयत्न करूया…कधी गर्लफ्रेंड मागे बसली म्हणून तर कधी गाडीच लेटेस्ट आहे म्हणून..कधी ऑफिसला उशिर झाला म्हणून तर कधी वाऱ्याशी स्पर्धा करायची म्हणून हा “मी” कट मारतो…. उजवीकडे वळायचं  म्हणून डाव्या लेनमधून अचानक उजव्या लेनमधे घुसतो.रस्त्यात मित्र दिसला म्हणून गाडी हवी तिथे थांबवून गप्पा कुटतो. या गोष्टी “मी” वैयक्तिक पातळीच्या सुविधांसाठी केल्या तरी  system  म्हणून याचा परिणाम काय हा विचार “मी” करत नाही. यात एक घटकाने म्हणजे “मी” लेन या संसाधनाचा ( resource )  गैरवापर केल्याने इतर घटकांसाठी हे संसाधन योग्य प्रकारे उपलब्ध न झाल्याने यंत्रणेमधला समन्वय बिघडतो. याचा परिणाम म्हणून यंत्रणा अपेक्षेप्रमाणे चालत नाही आणि बिघडवणारा घटक “मी” मला सोडून यंत्रणेतील इतर सर्व घटकांना दोष देतो. रोजच्या आयुष्यामधल्या अगदी छोट्या गोष्टीचं हे उदाहरण आहे…

 

सहज आठवलं .. परवा एकदा एक चिमुकली बाबाच्या पाठीमागे बसून गुणगुणत होती …. “गंमत झाली, काल मला स्वप्न पडलं छानसं, हिरव्या लाल दिव्याचा आदेश पाळायला लागली माणसं”…पुढचं काही ऐकूच आलं नाही मग…. तर ह्याच “मी” ने  यंत्रणेचा भाग म्हणून “माझी” भूमिका चोख बजावली ..म्हणजे वेगळं काहीच नाही पण “माझी सोय” हा एकमेव विचार सोडून… ठरलेले नियम “माझ्यासाठी” आहेत म्हणून पाळले तर हेच चित्र अगदी उलट व्हायला किती वेळ लागेल? आणि मुळात वाहन चालवणे ही फक्त गरज पेक्षा आनंद देणारी कृती होईल असं वाटतंय का? माझा वेळ , इंधनासाठी लागणारा पैसा, मनाची शांती हे फक्त कुणीतरी केलेले नियम पाळल्याने मला मिळू शकतात.. इतकंच नाही तर माझ्याकडून अनाठायी वाया जाणारं इंधन वाचल्यामुळे जिथे पोहोचतच नाही अशा ठिकाणी कुणाला तरी मिळण्याची शक्यता माझ्यामुळे निर्माण होते… शहरासाठी बनवल्या गेलेल्या सुविधांचं आयुष्यमान वाढू शकतं… पर्यावरण रक्षण , भ्रष्टाचारावर रोख हे फायदे तर अगदी नाही बघितले तरी डोक्याचा भुगा करणारी वाळवी माझ्यातून काढली की कुठेच उरणार नाही हे तरी  “सिस्टीम्स थिंकर” म्हणवून घेणाऱ्या “मला” कळतंय का?

फक्त “प्रोफेशन” मधे नाही तर माझ्या आजूबाजूला असणाऱ्या प्रत्येक यंत्रणेचा “मी” हा सर्वात महत्वाचा घटक आहे आणि नागरिक म्हणून, या समाजाचा घटक म्हणून प्रत्येक रचनेमधल्या “माझ्या” भूमिका “मी” डोळसपणे निभावतो आहे आणि प्रत्येक संसाधन जाणिवपूर्वक वापरतो आहे, हेच “स्मार्ट” असल्याचं लक्षण आहे… “स्मार्ट सिटी” या संकल्पनेमधे तज्ञ “वीज , पाणी, वेस्ट मॅनेजमेंट, स्वच्छता, ई-गव्हर्नंस आणि अशा कित्येक गोष्टींचा विचार करत आहेतच”… परंतु “माझ्यासाठी यंत्रणा” हा विचार बदलून “मी यंत्रणा” हा विचार प्रत्येक नागरिकाचा नसेल तर हे स्वप्न… कल्पनाविलासाच्या पलिकडे जाऊन साकारणं केवळ अशक्य आहे… ’पिंडी ते ब्रह्मांडी’ हा निसर्गनियम आहे… आपले अवयव आपापलं काम अविरत करत आहेत म्हणून आपण निरोगी आयुष्य जगतो आहे. तसंच “मी” समाजाचा अवयव आहे मग मी हातावरलं बोट आहे की धडामधलं पोट हा विचार गौण ठरतो…  systems thinking  ही सवय रक्तात भिनली तर स्मार्ट सिटी हेच आपलं प्रमाणपत्र असेल… नाही तर कागद मिळवून पुढे जाणं इतकचं या कोर्सचं स्वरूप होईल… शेवटी हातावरच्या १० बोटांवर  systems thinking  ची व्याख्या मांडता येईल “हे जर व्हायचं असेल तर हे “मला” च करावं लागेल” ….

गेल्या ३ महिन्यात जे कळलं नाही ते मागच्या ३० मिनिटात मांडायचा प्रयत्न ” certification committee” ने केला आणि पुढच्या प्रवासाचा  systems thinkers  वर सुपूर्त केला.

प्रशांत मिरजकर.

प्रेसिडेंट, बायोऍनॅलिटिकल टेक्नोलॉजिज,पुणे.

GIT : आपल्या computer वर install कसे करायचे? [भाग ३]

आपण मागील लेखात पाहिल्याप्रमाणे, आपल्याला लागणारी  पहिली गोष्ट म्हणजे GIT!
GIT ही प्रणाली आपल्या मशीनवर install करण्यासाठी http://git-scm.com/downloads येथून ती download करावी आणि पुढीलप्रमाणे ती install करता येईल.
Linux वर फक्त खालील command Terminal मध्ये run केली, की GIT install होईल.
sudo apt-get insall git-core
Windows वर तुम्ही download केलेली exe run करा.
GIT Install1
येथून “Next ” Click करा.

GIT Install2

हे License Agreement आहे. येथून “Next ” Click करा.

 

GIT Install3

ह्या ठिकाणी आपल्याला आपल्या सोयीनुसार path देता येतो. येथून “Next ” Click करा.

GIT Install4

GIT Install5

GIT Install6

वरील सर्व ठिकाणी आपण काहीही बदल न करता फक्त “Next” करत रहा.

 

GIT Install7

GIT Install8

 

त्यानंतर Installation चालू होईल आणि ही शेवटची स्क्रीन दिसेल. तुमच्या मशीनवर GIT install झाले असेल.

आपल्या “Programs” मध्ये “GIT Bash”अशा पर्यायाची भर पडलेली दिसेल.

आता राहिले Smartgit, ते आपण पुढील भागात पाहू.

GIT वापरायचे कसे ? [भाग -२]

GIT Image

आपण मागील लेखात पाहिल्याप्रमाणे GIT  ही  एक प्रणाली  आहे. तर ही प्रणाली वापरण्यासाठी  आपल्याला  नेमके  काय  काय गरजेचे  आहे ?
१)GIT
२)GIT Client
३)Hosting Provider
यापैकी  प्रत्येक  गोष्टीची  अधिक  विस्ताराने  माहिती  घेऊ.

  • GIT :   ही  प्रणाली आपल्याला  आपल्या  computer   वर  install  करावी  लागते.  मागील  लेखात  सांगितल्याप्रमाणे  GIT  मोफत  उपलब्ध  आहे .
    http://git-scm.com/downloads या  ठिकाणावरून  ते  download  करता  येते. जर  तुम्ही  Linux  वापरत  असाल  तर तुमच्या Terminal  मध्ये
    $ apt-get install git Command run करा .
  • GIT  Client :  GIT  हे  commands  वापरून  चालवता  येते. परंतु  आपल्या  सुलभतेसाठी  काही  clients  म्हणजे  अशी  softwares  जी  तुम्हाला  GIT  command  साठी काही  user interface  उपलब्ध  करुन  देतात. याद्वारे  तुम्ही अत्यंत  साध्या  सोप्या  गोष्टी  वापरून  GIT  शिकू  शकता.
    यासाठी  उपलब्ध  असलेला  Smart GIT  हा  पर्याय  आपण  पुढच्या  लेखामध्ये  पाहू.
  • HostingProvider :.
    यासाठी  देखील  काही  पर्याय  उपलब्ध  आहेत.
    १) GIT  Hub
    २)Bit Bucket

तर  वरील  प्रत्येक  गोष्ट  GIT  implement  करण्यासाठी  आवश्यक  आहे. परंतु  त्याही  आधी  काही  संज्ञा (Terminologies ) आपल्याला  माहीती  असणे  गरजेचे  आहे .
१)Repository–  आपला code व फाईल्स ज्या आपल्याला GIT वापरून जतन करायच्या आहेत त्या ज्या डिरेक्टरीमध्ये आहेत ती आपली “Repository”, म्हणजेच “Storage Location”.
२)GIT  commands – GIT वापरण्यासाठी काही commands आपल्याला माहीत असणे आवश्यक आहे.

git init: एखादी डिरेक्टरी आपल्याला “Repository” म्हणून घोषित करायची असेल तर त्यासाठी ही command वापरली जाते.

git status: आपल्या Repository चे status जाणून घेण्यासाठी ही command वापरली जाते. कोणत्या फाईल्सची भर पडलेली आहे(GIT द्वारे न जोडलेल्या), कोणत्या फाइल्स बदलल्या आहेत, कोणत्या काढून टाकल्या आहेत याची सर्व माहिती ह्या command द्वारे मिळते. प्रत्येक वेळी ही command run करणे फायद्याचे ठरते कारण सगळे बदल आपल्याला लगेच लक्षात येतात.

git pull: एकापेक्षा जास्त लोक जर repository वापरत असतील तर त्यांनी केलेले बदल आपण समाविष्ट करून घेणे आवश्यक आहे. त्यासाठी ही command वापरली जाते. आपण केलेल्या बदलांना धक्का न लावता ही command ते बदल समाविष्ट करून घेते.

git commit: आता आपण बदल केलेल्या फाइल्स git मध्ये अद्ययावत करणे हे काम commit ही command करते. त्याचप्रमाणे, काय बदल केले ह्याची माहिती सुद्धा आपण या command द्वारे लिहून ठेऊ शकतो. त्यासाठी git commit -m “आपण केलेला बदल ” अशी वापरावी.

git push: आपण केलेले बदल इंटरनेटवरील repository वर म्हणजेच “Remote  repository”वर टाकायचे असल्यास ही command वापरली जाते. या command द्वारे आपण केलेले सर्व बदल एका version मध्ये सुरक्षित रहातात.

या commands जर वापरून पाहायच्या असतील तर GIT ने त्यांच्याच साईटवर एक छान सोय दिली आहे.

http://try.github.io/levels/1/challenges/3 येथे जाऊन तुम्ही या commands प्रत्यक्ष वापरून पाहू शकता.

git ही अतिशय सोपी आणि उपयोगी गोष्ट आहे. आता हे सर्व configuration आपल्या कॉम्पुटरवर कसे करायचे ते पुढील लेखात पाहू.

GIT: म्हणजे नेमके काय? [भाग -१]

GIT Image
GIT : म्हणजे नेमके काय?
खरे तर GIT म्हणजे Version Control And Source Code Management System
Version म्हणजे आवृत्ती. मग कशाची आवृत्ती? आपण GIT म्हणजे फक्त Software प्रोजेक्ट्स संदर्भातच वापरली जाणारी प्रणाली असे ऐकले असेल. पण या क्षेत्रात जरी ती मोठ्या प्रमाणात वापरली जात असेल तरी कोणत्याही प्रकारची फ़ाईल आपण GIT मध्ये संलग्न करून वापरू शकतो. म्हणजेच GIT ही Document Control System म्हणूनही वापरली जाते. Software प्रोजेक्ट्स बाबतीत बोलायचे झाल्यास, आपण लिहिलेला कोड (code) एकत्रितपणे पण प्रत्येक वेळी नव्या आवृत्तीप्रमाणे संचय करणारी एक व्यवस्था म्हणजे GIT.

आता उदाहरण द्यायचे झाल्यास, समजा, २ लोक एकाच प्रोजेक्टवर काम करत आहेत. मग आता जर एकाने काही काम केले आणि दुसऱ्याने काही आणखी काम केले तर आपल्याला ह्या दोन गोष्टी एकत्र करायला काय करावे लागेल? एका ठिकाणाहून Copy आणि दुसरीकडे Paste:) बरोबर ना? मग ह्या प्रकारात इकडे-तिकडे काहीतरी गोंधळ होतात आणि चालणारे software चालेनासे होते. त्याचप्रमाणे जर बदल केलेली प्रत्येक आवृत्ती आपणांस सांभाळायची असेल तर काय? एकाच ठिकाणी दोघांना बदल करायचा असेल, तर काय? आता केलेले बदल नाहीसे करून पूर्ववत करायचे असेल तर? एका तयार आवृत्तीपासून परत २-३ वेगळ्या आवृत्ती करायच्या असल्यास काय? असे अनेक प्रश्न आहेत ज्यांचे उत्तर आहे GIT!
म्हणजे वर दिलेले सर्व घटनाक्रम लक्षात घेऊन त्या सर्व बाबींसकट तुमच्या source code ची काळजी घेणारी ही एक प्रणाली आहे.

जशी GIT ही एक प्रणाली आहे त्याचप्रमाणे आणखी काही प्रणालीदेखील अस्तित्वात आहेत जसे की, SVN, Mercurial इ. मात्र या लेखमालेत आपण GIT विषयीच शिकणार आहोत.

GIT च्या इतिहासाविषयी थोडेसे:
GIT प्रणाली तयार होण्यामागे एक गोष्ट दडलेली आहे. आपल्याला माहित आहे की Linux कर्नल हे Open Source आणि अतिशय व्यापक प्रोजेक्ट आहे. ह्या प्रोजेक्टवर अनेक जण काम करत असल्याने लहान लहान तुकड्यामध्ये ते विकसीत झाले.Linux च्या सुरवातीच्या बऱ्याच काळात (१९९१ ते २००२) वेळोवेळी केलेले बदल archived फाईल्सच्या माध्यमात संग्रहीत केले जात. २००२ मध्ये मात्र यासाठी linux community, BitKeeper नावाची एक Propritory DVCS System वापरु लागले. २००५ मध्ये मात्र Linux आणि ही कंपनी यांत वाद झाल्याने ही मोफत सेवा बंद करण्यात आली. आणि हीच गोष्ट Linux Community, प्रामुख्याने लायनस टोरव्हॉल्ड्स (Linus Torvalds) Linux चा जनक, ह्यांना GIT निर्माण करण्यास प्रेरक ठरली व GIT चा जन्म झाला.
ही सुविधा तयार करताना प्रामुख्याने खलील बाबींचा विचार करणात आला:

  • Speed (वेग)
  • Simple design (साधं-सोप्पं design )
  • Strong support for non-linear development (thousands of parallel branches)
  • Fully distributed
  • Able to handle large projects like the Linux kernel efficiently (speed and data size)

२००५ पासून linux ही वापरण्यासाठी अतिशय सुलभ आणि वरील सर्ब बाबी अंतर्भूत असलेली सक्षम प्रणाली म्हणूनच सर्वमान्य आहे.
GIT हे मोफत उपलब्ध असून GNU( General Public License) च्या अंतर्गत वितरीत केले जाते.

GIT कसे वापरायचे, त्यासाठी कोणकोणते मार्ग उपलब्ध आहेत हे आपण पुढील भागात पाहू.

(छायाचित्र : आंतरजालावरून साभार)

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

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

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

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


WAMP सर्व्हर कसा कार्यान्वित करायचा?

WAMP म्हणजे Windows, Apache, MySQL आणि PHP. WAMP सर्व्हर हे असे एक software आहे जे तुमच्या संगणकावर Apache, MySQL आणि PHP या तीनही गोष्टी कार्यान्वित करत.
या लेखात आपण WAMP सर्व्हर आपल्या संगणकावर कसा कार्यान्वित करायचा ते पाहणार आहोत.

WAMP म्हणजे Windows, Apache, MySQL आणि PHP. WAMP  सर्व्हर हे असे एक software  आहे जे तुमच्या संगणकावर Apache, MySQL आणि PHP या तीनही गोष्टी कार्यान्वित करत.
या लेखात आपण WAMP सर्व्हर आपल्या संगणकावर कसा कार्यान्वित करायचा ते पाहणार आहोत.
WAMP सर्व्हर कसा कार्यान्वित करायचा?
WAMP सर्व्हर तुह्मी इथून डाउनलोड  करू शकता.
१. तुह्मी डाउनलोड केलेल्या फाइलवर दोनदा क्लिक करा. आता तुम्हाला खाली दिल्याप्रमाणे  स्क्रीन दिसेल. स्क्रीनवरील Next या बटणावर क्लिक करा.
२. आता तुह्माला खाली दाखविल्याप्रमाणे License Agreement ची स्क्रीन दिसेल. स्कीनवर दाखवल्याप्रमाणे  I accept  the agreement हा पर्याय निवडा व Next या बटणावर क्लिक करा.
३. आता तुह्माला WAMP सर्व्हरसाठी आपल्या संगणकावरील जागा निवडायची आहे.  इनस्टोलर C:\WAMP हि जागा निवडतो ती जागा आपल्याला बदलायची असल्यास Browse या बटणावर क्लिक करा व तुह्माला हवी असलेली जागा निवडा व Next या बटणावर क्लिक करा.
४.त्यानंतर खाली दिल्याप्रमाणे installation च्या उर्वरीत पायरया पूर्ण करा.
५.आता software  installation साठी तयार आहे. Install या बटणावर क्लिक करा म्हणजे आता तुमच्या संगणकावर PHP, MySQL आणि  Apache sever कार्यान्वित होईल.
६.आता तुम्हाला browser निवडायचा आहे. तुमच्या संगणकावर असलेल्या beowser पैकी कुठलाहि browser तुह्मी निवडू शकता. खाली दाखवलेल्या स्क्रीनमध्ये internet explorer हा पर्याय निवडला आहे. browser निवडून झाल्यावर open या बटणावर क्लिक करा.
७.आता तुह्माला installar SMTP Setting विषयी विचारेल. तुह्माला त्याबद्दल काही माहित   नसल्यास आहे तेच Setting राहु द्या व Next या बटणावर क्लिक करा.
८.आता तुमचे  installtion पूर्ण झाले आहे. Finish या बटणावर क्लिक करा.

९.आता तुमच्या संगणकावरील टास्कबारवर WAMP चा  छोटासा आयकॉन दिसेल त्यावर क्लिक करा व त्यावरील localhost हा पर्याय निवडा.

तुह्मी निवडलेल्या browser वर तुह्माला खाली दाखवल्याप्रमाणे स्क्रीन दिसेल.याचा अर्थ तुमच्या संगणकावर WAMP  सर्व्हर कार्यान्वित झाला.

अशाप्रकारे तुह्मी तुमच्या संगणकावर WAMP सर्व्हर कार्यान्वित (install ) करू  शकता.
WAMP सर्व्हरवर wordpress कसं कार्यान्वित करायचं ते पुढील लेखात पाहू.