चपळ विकास

"हाय, अमिगो!"

"हाय, बिलाबो!"

"आज मी तुम्हाला प्रोग्राम्स सहसा कसे विकसित केले जातात याबद्दल सांगणार आहे."

"20 व्या शतकात, जेव्हा आधुनिक IT बाल्यावस्थेत होते, तेव्हा प्रत्येकाला असे वाटू लागले की प्रोग्रामिंग हे बांधकाम किंवा उत्पादनासारखे आहे."

"गोष्टी सहसा यासारख्या घडतात:"

" ग्राहक त्याला आवश्यक असलेल्या प्रोग्रामचा प्रकार स्पष्ट करेल - त्याने काय करावे आणि ते कसे करावे."

" व्यवसाय विश्लेषक त्यांचे म्हणणे ऐकतील आणि त्यांनी जे सांगितले त्यावर आधारित कार्यक्रम आवश्यकतांची संपूर्ण यादी तयार करतील."

"मग प्रकल्प व्यवस्थापक या आवश्यकतांची कार्यांमध्ये विभागणी करतील आणि कोणता प्रोग्रामर कोणते कार्य आणि कोणत्या क्रमाने करेल हे देखील ठरवेल."

"मग प्रोग्रामर कामाला लागतील. कधीकधी ते अनेक वर्षे काम करतील(!)."

"ते पूर्ण झाल्यावर, कार्यक्रम परीक्षकांना देण्यात आला."

" त्यांची अंमलबजावणी झाली आहे आणि प्रोग्राम जसा अपेक्षित होता तसे काम केले आहे हे सत्यापित करण्यासाठी परीक्षक प्रोग्रामच्या प्रत्येक आवश्यकतांमधून जातील."

"काही चुकले तर, परीक्षक बग लॉग करतील आणि प्रोग्रामरला पाठवतील."

"मग प्रोग्रामर बग्स दुरुस्त करतील आणि निश्चित प्रोग्राम परत परीक्षकांना पाठवतील. आणि सायकलची पुनरावृत्ती होईल."

"जेव्हा मुख्य दोष निश्चित केले गेले, तेव्हा कार्यक्रम ग्राहकाला देण्यात आला."

"अशाच गोष्टी घडल्या?"

"ठीक आहे, अर्थातच, मी बरेच काही सोपे केले आहे, परंतु गोष्टी कशा केल्या होत्या त्या अगदी जवळ आहे."

"आणि एक प्रकल्प पूर्ण होण्यासाठी खरोखर दीड ते दोन वर्षे लागू शकतात?"

"कधीकधी एखाद्या प्रकल्पाचा विकास खरोखरच लांबला असेल, तर ते त्याला स्वतंत्र प्रकाशनांमध्ये मोडतात. दर 3-6 महिन्यांनी, विकासकांना प्रोग्रामच्या कार्यक्षमतेचा एक विशिष्ट भाग तयार करावा लागतो, त्याची चाचणी घ्यावी लागते, त्यातील सर्व दोषांचे निराकरण करावे लागते आणि त्यांना ते दाखवावे लागते. ग्राहक."

"प्रथम, जेणेकरून तो त्याचे इंप्रेशन सामायिक करू शकेल. आणि दुसरे, आणि महत्त्वाचे म्हणजे, जेणेकरून तो प्रोग्रामच्या विकासासाठी पैसे देत राहील."

"पैसे देत राहू?"

"तेव्हा, विकासाला नियोजित वेळेपेक्षा 2-3 पट जास्त वेळ लागत होता. आणि प्रोग्रामरना अनेकदा तासाला पैसे दिले जात असल्यामुळे, प्रोग्राम 2-3 पट जास्त महाग झाला. इतकेच काय, फायदे देखील कमी झाले. शेवटी, ग्राहकाला आज काय हवे आहे 3 वर्षांत $100,000 ची गरज भासणार नाही - विशेषत: तिप्पट किमतीत."

"ग्राहकांनी अनेकदा पैसे देण्यास नकार दिला का?"

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

"पण का?"

"ठीक आहे, प्रथम, नियोजनाच्या टप्प्यात खूप कमी माहिती आहे. बहुतेक वेळा, सुरुवातीला, प्रोग्रामरना कोणत्या समस्यांना सामोरे जावे लागेल हे कोणीही सांगू शकत नाही."

"पण अनुभवी प्रोग्रामर सर्व गोष्टींचा अंदाज घेण्यास सक्षम असावेत, बरोबर?"

"तुम्ही पाहू शकता की प्रोग्रामिंग हा एक अद्वितीय व्यवसाय आहे."

"एक सामान्य कार्यकर्ता वारंवार तेच काम वारंवार करतो. वॉचमेकर घड्याळे बनवतात, स्वयंपाक करतात, शिक्षक शिकवतात, डॉक्टर उपचार करतात इ."

"यापैकी प्रत्येक व्यावसायिक मुळात दिवसेंदिवस एकच काम करतो. परिणामी, ते त्यांच्या नोकऱ्यांमध्ये अधिक चांगले होऊ लागतात."

"प्रोग्रामिंगमध्ये, दृष्टीकोन भिन्न आहे. प्रोग्रामरला दररोज त्याच कार्याला सामोरे जावे लागताच, तो ते करण्यासाठी फंक्शन, मॉड्यूल किंवा प्रोग्राम लिहितो आणि पुन्हा त्याकडे परत येत नाही."

"प्रत्येक प्रोग्रामर सहसा प्रत्येक कार्य त्याच्या आयुष्यात एकदाच सोडवतो."

"वैज्ञानिक किंवा डिझाइन अभियंते सारखे काहीतरी जे शोध लावतात."

"अहो. बरं, प्रोजेक्टमध्ये सर्वात महत्त्वाची भूमिका कोणती आहे?"

"हम्म, मी याचे उत्तर कसे द्यावे. सर्वात महत्वाचे कोणते हे सांगणे सोपे आहे, परंतु सर्वात महत्वाचे ओळखणे कठीण आहे."

" परीक्षकाचे प्राथमिक काम ( Q uality  A surance , QA )  हे एखाद्या प्रोग्रामच्या स्थितीचे निरीक्षण करणे आणि बग्सचा त्वरित अहवाल देणे आहे. जितक्या लवकर परीक्षकाला बग सापडतील, तितकेच त्याचे निराकरण केले जाऊ शकते.  एक चांगला परीक्षक उत्पादनाच्या गुणवत्तेवर अधिक प्रभाव पाडतो. एक चांगला प्रोग्रामर करतो ."

"प्रोग्रामर त्यांच्या स्वतःच्या प्रोग्रामची चाचणी का करू शकत नाही. शेवटी, काय काम करते आणि काय करत नाही हे त्यांना परीक्षकांपेक्षा चांगले माहित नाही?"

"एक चांगला प्रोग्रामर फक्त एक चांगला परीक्षक होण्यास असमर्थ असतो. प्रोग्रामर खरोखर कसे चांगले कार्य करते हे एका प्रोग्रामरला माहित असते, म्हणून तो किंवा ती नेहमीच एका विशिष्ट प्रकारे वापरतो. सामान्य वापरकर्त्यांच्या विरूद्ध जे त्यांना हवे असले तरीही प्रोग्राम वापरतात. "

"याशिवाय, परीक्षक अद्याप काय काम करत नाही ते तपासत नाहीत. परीक्षक कार्यक्षमतेची किंवा प्रोग्रामच्या काही भागांची चाचणी घेतो ज्याला प्रोग्रामर म्हणतो की ते आधीच जवळजवळ पूर्णपणे काम करत आहेत."

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

" प्रोग्रामरचे प्राथमिक कार्य ( S oftware  D eveloper  E ngineer ,  D eveloper ,  SDE ) हे नवीन कार्यक्षमतेची अंमलबजावणी करणे आहे. किंवा अधिक सोप्या भाषेत सांगायचे तर, त्याला किंवा तिला नियुक्त केलेली कार्ये पूर्ण करणे. जेव्हा प्रोग्रामरना नवीन वैशिष्ट्यांसह कार्ये नियुक्त केली जातात , ते ते पूर्ण करतात. जेव्हा त्यांना बग नियुक्त केले जातात, तेव्हा ते दोष दूर करतात."

"परंतु काहीवेळा आणखी आव्हानात्मक कार्ये असतात, उदाहरणार्थ, प्रोग्राम किंवा त्यातील काही भागांसाठी आर्किटेक्चर घेऊन या. प्रस्तावित आर्किटेक्चर जितके चांगले असेल तितके भविष्यात गोष्टी पूर्ण करणे सोपे होईल."

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

"याव्यतिरिक्त, जर आर्किटेक्चर यशस्वी झाले आणि प्रोग्राम उत्कृष्ट झाला, तर ग्राहक कदाचित प्रोग्रामच्या नवीन आवृत्त्यांसाठी आधार म्हणून वापरू इच्छित असेल."

"मला जे मिळत आहे ते येथे आहे."

"तुम्ही कोणतेही आर्किटेक्चर निवडता, तेथे नेहमीच बदल, जोडणी आणि नवीन वैशिष्ट्यांचा समूह असेल ज्याचा आर्किटेक्चरचा विचार नाही."

"हे एक चांगले उदाहरण आहे."

"एक ग्राहक तुम्हाला 5 मजली इमारत बांधायला सांगतो, म्हणून तुम्ही वास्तू डिझाइन करा आणि घर बांधता."

"मग ग्राहक दुसरी कथा जोडण्यास सांगतो, आणि नंतर दुसरी, आणि असेच."

"पण पहिल्या मजल्याच्या भिंती इतक्या वजनासाठी तयार केल्या गेल्या नाहीत आणि पायाही नाही. त्यामुळे सर्वकाही पुन्हा करावे लागेल."

"पण 5 मजली इमारत झाल्यानंतर, जर ग्राहकाने लगेच ठरवले की त्याला 50 मजली इमारत हवी आहे?"

"विद्यमान संरचना पाडणे आणि सुरवातीपासून सर्वकाही पुन्हा तयार करणे सोपे होईल..."

"पण माझ्याकडे तुमच्यासाठी आर्किटेक्चरच्या संदर्भात एक सल्ला आहे."

"एखाद्या ऍप्लिकेशनचे आर्किटेक्चर, सर्वप्रथम, लवचिक असणे आवश्यक आहे, याचा अर्थ तुम्ही ऍप्लिकेशनचा अर्धा भाग पुन्हा करण्याचा निर्णय घेतल्यास तुम्हाला सुरवातीपासून सुरुवात करावी लागणार नाही. या प्रकारच्या आर्किटेक्चरला सहसा लवचिक आणि मॉड्यूलर म्हणतात . "

" प्रोजेक्ट मॅनेजरचे प्राथमिक काम निर्णय घेणे असते. प्रोजेक्ट मॅनेजर हा तो असतो जो मोठे चित्र पाहतो आणि त्या दृष्टीकोनावर आधारित निर्णय घेतो."

"समजा, विकासादरम्यान हे स्पष्ट झाले की एखादे कार्य नियोजित प्रमाणे पूर्ण होणार नाही. प्रकल्प व्यवस्थापक हे करू शकतात:"

" अ)  कार्य सुधारण्यासाठी ग्राहकाशी वाटाघाटी करण्याचा प्रयत्न करा"

" ब)  कार्यासाठी अधिक वेळ द्या"

" c)  इतर प्रकल्पांमधून अधिक अनुभवी प्रोग्रामर आणा."

"आणि इतर अनेक शक्यता आहेत."

"प्रत्येक पर्यायासाठी तुम्हाला काहीतरी बलिदान देणे आवश्यक आहे आणि व्यवस्थापकाचे काम या यज्ञांमधून होणारे एकूण नुकसान कमी करणे आहे. "

"उदाहरणार्थ, समजा स्पर्धकांनी लीड प्रोग्रामरला दुप्पट पैसे देऊन चोरी केली."

"प्रकल्प व्यवस्थापक हे करू शकतो:"

" अ)  काहीही करू नका. प्रोग्रामर निघून जाईल, आणि प्रकल्प मागे पडण्याची शक्यता आहे आणि दंड भरावा लागेल."

" ब)  त्याचा पगार दुप्पट करा. मग टीममधील इतर प्रत्येकालाही वाढ हवी असेल. जर तुम्ही त्या सर्वांना जास्त पैसे दिले तर प्रकल्पाचा खर्च वाढेल आणि तो फायद्याचा नाही."

" c)  तुम्ही विचार करता असा काही दुसरा पर्याय."

"मी बघतो."

"खराब प्रोजेक्ट मॅनेजरसह, चांगली टीम सहसा प्रोजेक्ट लांबवते, परंतु नेहमीच नाही."

"सरासरी प्रोग्रामरच्या टीमसह एक चांगला व्यवस्थापक नेहमीच उत्कृष्ट प्रोग्रामरच्या टीमसह खराब व्यवस्थापकापेक्षा एक प्रकल्प जलद पूर्ण करेल."

"मी बघतो."

"ठीक आहे, चला थोडा ब्रेक घेऊ आणि मग आपण पुढे जाऊ."