समजा कि तुम्हाला घर रंगवायचे आहे. हे काम किती मोठे आहे? ह्याचे उत्तर १००० स्क़े फू हेच असू शकते. हे आपण माझ्या आधीच्या blog मध्ये पहिले. एखाद्या कामाला किती वेळ लागेल ह्याचे उत्तर देताना पहिले आपण ते काम किती मोठे आहे ह्याचाच विचार आधी करतो. आणि त्यामुळे effort estimate पेक्षा size estimate जास्ती योग्य ठरू शकेल हे सुद्धा आपण माझ्या आधीच्या blog मध्ये पहिले आहेच. पण घराचा size किंवा लग्नात लागणाऱ्या लाडवाचा size estimate करणे सोपे आहे हो. एखादे software किती मोठे आहे ह्याचे उत्तर तेवढे सोपे नक्कीच नाही!

पण आपण software चा size मोजू शकलो तर बरेच प्रश्न सुटू शकतील 🙂 . आता आपण हे पाहू कि हा software चा size शोधण्यासाठी काही trick आहे का?

Relative (तुलनात्मक) sizing

ही तशी काही नवीन संकल्पना नाही. आपण आपल्या आयुष्यातले सगळे measurements relative sizing नेच करतो. उदाहरणार्थ – कुणीतरी ठरवले कि एका ठराविक अंतराला ला १ फूट म्हणावे. मग आता मी जर त्या ठराविक लांबीच्या ६ पट लांब असेन तर माझी उंची ६ फूट झाली 🙂

तसेच कुणीतरी म्हणाले कि एका ठराविक पाण्याच्या साठ्याला १ लिटर म्हणावे. मग मला त्याच्या १० पट पाणी एखाद्या भांड्यात दिसले तर त्या भांड्यात १० लिटर पाणी आहे असे आपण म्हणू!

अंतर, वजन, घनता, लांबी, सगळे काही आपण तुलनात्मकच तर मोजतो की! फरक इतकाच कि आपण ज्याच्याशी तुलना करतो ते एक प्रमाण (standard) मानले गेले आहे.

मग आता software चा size आपण असा तुलनात्मक पद्धतीचा अवलंब करून मोजू शकतो का? असा विचार काही जणांनी केला.

संकल्पना समजण्या साठी एक सोपे उदाहरण घेऊयात – असे समजा कि आज घरी पाहुणे जेवायला येणार आहेत. आमटी, साधा भात, हिरवी चटणी, काकडीची कोशिंबीर, बटाट्याची भाजी आणि पुरण पोळी असा बेत आहे. आता ही झाली जेवणाची वेगवेळी features 🙂

1. ह्यातले सगळ्यात सोप्पे feature – साधा भात ह्याला प्रमाण पकडा (कारण ह्यात लागणारा effort, त्याची complexities आणि risks सगळ्यात कमी आहेत). त्याला २ जेवण points म्हणूयात
2. आता जर साधा भात २ जेवण points असेल तर आमटी हे deliverable किती मोठे असेल? दोन्हीही कुकारातूनच काढायचे आहेत, पण आता आमटी मध्ये काम जास्ती आहे, रिस्क किंवा complexities सुद्धा किंचित जास्ती आहेत साध्या भातापेक्षा – so, आपण आमटी ला ३ जेवण points देवूयात 🙂
3. म्हणजे आमटी हे deliverable साध्या भातापेक्षा साधारण दीडपट मोठे आहे!
4. आता कोशिंबीर घ्या – काकडीची साले काढणे, त्या कोचणे, पाणी काढणे, फोडणी देणे – ह्यात सुद्धा साध्या भातापेक्षा काम जास्ती आहे, रिस्क किंवा complexities किंचित जास्ती आहे, साध्या भातापेक्षा, पण हे काम आमटीपेक्षाही थोडे मोठे आहे. So आपण ह्याला ५ जेवण points देवूयात
5. आणि आता पुरण पोळी – हे फारच complicated deliverable आहे ह्याची साध्या भाताशी सरळ तुलना अवघड आहे 🙂
6. मग आता ह्या deliverable ला आपण ४ भागात विभागूयात –
   1. शिजवलेले पुरण
   2. पुरण यंत्रातून एकजीव केलेले पुरण
   3. पोळीसाठी मळलेली कणिक आणि
   4. लाटून भाजलेली पोळी 🙂
7. आता शिजवलेले पुरण हे भात शिजवान्याशी compare होऊ शकेल – say २ points
8. पुरण यंत्रातून एकजीव केलेले पुरण – हे कोशिंबीर पेक्षाही मोठे काम असेल – say ८ points
9. Finally – प्रत्येक पुरण पोळी हि साधारण ३ points ची असू शकते (भातापेक्षा किंचित मोठे काम) – २० पोळ्यांचे ६० points
10. हे सगळे points एकत्र केले कि जेवणाचा size मिळेल – say १०० points 🙂

आता एका तासात जर आमटी, भात, पुरण शिजवणे, चटणी आणि कोशिंबीर असे काम होऊ शकेल – म्हणजेच साधारण १७ ते २० जेवण points चे काम १ तासात होऊ शकते (ह्यालाच “velocity असे म्हणतात 🙂 ) – म्हणजेच ह्या पूर्ण जेवण बनवण्याच्या प्रोजेक्ट ला ५ ते ६ तास लागू शकतात! मिळाले कि आपल्याला उत्तर Relative (तुलनात्मक) sizing ने!

आता हीच संकल्पना software प्रोजेक्ट ला apply करूयात. समजा तुम्ही बनवत असलेल्या software मध्ये १०० features आहेत. त्यापैकी त्यातल्यात्यात सगळ्यात सोपे, कमी risks आणि complexities असलेले feature घ्या आणि त्याला प्रमाण माना – त्याला १ (किंवा काहीही) म्हणा! आता जर का हे feature १ point असेल तर तुमच्या software मधले प्रत्येक दुसरे feature ह्या प्रमाण मानलेल्या feature शी compare करा आणि तुलनात्मक दृष्ट्या ते किती मोठे आहे ते ठरवा. समजा एखाद्या feature ला लागणारा वेळ, त्यातली risks आणि complexities जर प्रमाण मानलेल्या feature पेक्षा तिप्पट वाटत असेल तर त्याला ३ points द्या. असे करत प्रत्येक feature ला काही न काही points मिळतील. सगळ्या १०० features ला मिळून जर समजा २०० points झाले, तर “हे software २०० points मोठे आहे” असे उत्तर आपल्याला मिळेल 🙂

– चिंगुडे