மென்பொருள் உருவாக்கும் விந்தையுலகம் 4: திட்டம் 40% முடிந்தும் நிரல் ஒரு வரி கூட இல்லை ஆனால் ஆவணங்களோ ஒரு அடுக்கு!

கணியம் பொறுப்பாசிரியர் September 4, 2015 3 Comments

 

Agile/Scrum பற்றி தொடர் கட்டுரை – 4

 

நான் அப்போது அமெரிக்காவில் ஒரு மத்திய அரசாங்கத் துறையில் ஆலோசகராக இருந்தேன். கூடிப்பேச சென்றிருந்த திட்ட இயக்குனர் அப்பொழுதுதான் திரும்பி வந்திருந்தார், அதிர்ச்சியுடன் காணப்பட்டார். அந்த நிகழ்ச்சியில் நடந்தது பற்றி யாரிடமாவது சொல்லா விட்டால் மண்டை வெடித்து விடும் நிலையில் இருந்தார். ஒப்பந்தக்காரர்கள் உருவாக்கிய மென்பொருளைக் காட்டி, விளக்கி, கொண்டு சேர்க்க வந்திருந்தனராம். ஒப்பந்தத்திலுள்ள தேவைப் பட்டியல்படி மூன்று ஆண்டுகளாகக் கடுமையாக உழைத்து உருவாக்கியதென்று கூறினார்களாம். செயல்முறைக்காட்சியின் இறுதியில் வாடிக்கையாளர் அணி, “இதுவல்ல நாங்கள் கேட்டது” என்று கூறி அந்த முழு விநியோகத்தையும் அறவே நிராகரித்து விட்டனராம்.

 

மென்பொருள் திட்டங்களில் இது போன்ற பெரும் நெருக்கடிகள் ஏன் ஏற்படுகின்றன என்று புரிந்து கொள்ள நாம் அருவி செயல்முறை (Waterfall Method) என்றால் என்ன, அது எங்கிருந்து வந்தது, எப்படி வேலை செய்கிறதென்று தெரிந்து கொள்ள வேண்டும். உற்பத்தி மற்றும் கட்டுமான தொழில்துறை திட்டங்களில் இந்த செயல்முறை உருவானது. இத் தொழில்துறைகளில் வேலையை ஒரு முறை செய்த பிறகு அதை மாற்றியமைப்பது சில சமயம் சாத்தியமேயில்லை. மற்ற சமயங்களில் சிறு மாற்றங்கள் கூட அதிக நேரம் எடுக்கும், அநியாய செலவு வைக்கும். எடுத்துக்காட்டாக, கான்கிரீட் போட்ட பின்னர் வடிவமைப்பை மாற்ற விரும்பினால் எப்படி செய்வதென்று எண்ணிப் பாருங்கள்.

 

இப்படி இருக்கும்போது வடிவமைப்பை முற்றிலும் திருப்தியாக முடித்து வாடிக்கையாளரிடம் கையெழுத்தும் வாங்கிய பின் கட்டுமான வேலையைத் தொடங்குவீர்களா? அல்லது கட்ட ஆரம்பித்த பின் திரும்பிச் சென்று வடிவமைப்பைக் கொஞ்சம் அழகு படுத்துவீர்களா?

 

மென்பொருள் உருவாக்கத்தில் இதைத்தான் நாம் அருவி செயல்முறை என்கிறோம். ஏனென்றால் இதில் முன்னேற்றம் ஒவ்வொரு கட்டத்திலும் கீழ்நோக்கி படிப்படியாக அருவி போன்று பாய்கிறது. ஒவ்வொரு கட்டத்தையும் ஒரு முறைக்கு இரண்டு முறை சரிபார்த்து விட்டுத்தான் அடுத்த கட்டத்துக்குச் செல்வீர்கள். முன்னால் முடித்த கட்டத்துக்கு ஒரு போதும் திரும்பிச் செல்ல மாட்டீர்கள்.

commons.wikimedia.org/wiki/File:Waterfall_model_%281%29.svg

 

மென்பொருள் திட்டங்கள் ஆரம்பித்த காலத்தில் திட்ட மேலாளர்களும் மூத்த நிர்வாகிகளும் இந்த முறையில் மற்ற பல திட்டப்பணிகளை நிர்வகித்து அனுபவம் பெற்றிருந்தனர். மேலும், இவர்களுக்கு பரிச்சயமான, வழக்கமாகப் பயன்படுத்தும் திட்ட மேலாண்மைக்கான மென்பொருட்களில் இந்தச் செயல்முறை உள்ளிடப்பட்டு இருந்தது. ஆகவே இந்தச் செயல்முறையையே இயல்பாகப் பின்பற்றினர்.

 

இது போதாதென்று பல ஆண்டுகளுக்கு முன் செய்த ஒரு ஆராய்ச்சியின்படி மென்பொருள் உருவாக்கும் போது ஆரம்ப கட்டங்களில் ஒரு வழுவை நீக்குவது எளிது, ஆகையினால் அதற்கான செலவும் குறைவு. அதே வழுவை பின்னர் வரும் கட்டங்களில் நீக்க 50 முதல் 200 மடங்கு அதிக செலவாகலாம் என்ற முடிவு வெளி வந்தது. ஆனால் இந்த ஆராய்ச்சி FORTRAN மற்றும் COBOL மொழிகளில் நிரலாக்கம் எழுதி, துளையிடப்பட்ட அட்டைகளில் உள்ளீடு செய்த காலத்தில் நடந்தது. இந்த மொழிகளை அப்போது தொகுப்பதும், சோதனை செய்வதும் மிக மெதுவாகத்தான் நடக்கும், அதற்கான செலவும் அதிகம். எனினும் இது எக்காலத்திலும் எம்மொழிக்கும் பொருந்தும் என்று பரவலாக நம்பப்பட்டது. இதன் காரணமாக முன்னால் உள்ள கட்டங்களில் வழுக்கள் ஏற்டாமல் இருக்க பகீரதப் பிரயத்தனம் செய்தனர்.

 

மேற்கண்ட காரணங்களாலோ, அல்லது அரசாங்க வகை எழுத்துமூல ஒப்பந்தங்கள் செயல்படுத்துவது எளிதாக இருக்கும் என்றோ மென்பொருள் கொள்முதலுக்கு அருவி செயல்முறையையே பின்பற்றுவதென அமெரிக்க அரசாங்க பாதுகாப்புத் துறை முடிவு செய்தது. மற்ற அரசாங்கத் துறைகளும், பெரிய நிறுவனங்களும் பின் தொடர்ந்தன. இதுவே மேலோங்கிய செயல்முறையாக நிலைபெற்றது.

 

பொதுவாக நடைமுறையில், அருவி முறை எப்படி செயல் பட்டது என்று பார்ப்போம். இதன் முதல் படியாக தேவைகள் பட்டியல் தயார் செய்து வாடிக்கையாளர்கள் அதில் கையெழுத்திட்டு ஒப்புதல் கொடுத்து விட்டார்கள் என்று வைத்துக்கொள்வோம். திட்ட மேலாளர்கள் தொழில்நுட்ப குழுவுடன் அமர்ந்து முழுத் திட்டத்தையும் முடிக்க என்னென்ன வேலைகள் செய்ய வேண்டும், அவை ஒவ்வொன்றுக்கும் எவ்வளவு நேரம் எடுக்குமென்ற பட்டியல் தயார் செய்வர். இதை பணிக் கூறுகள் அமைப்பு (Work breakdown structure) என்று சொல்கிறோம். இத்துடன் இப் பணிகளின் சார்புநிலையையும் (dependency) குறிப்பெடுக்க வேண்டும். அதாவது ஒரு பணியை ஆரம்பிக்கும் முன் அது சார்ந்திருக்கும் எந்தெந்த பணிகள் முடிந்திருக்க வேண்டும் என்பது. எடுத்துக்காட்டாக, சுவற்றில் வெள்ளை அடிக்கும் முன் சிமெண்ட் பூசிக் காய்ந்திருக்க வேண்டும் அல்லவா? என்னதான் அவசரம் என்றாலும் இதை மாற்றிச் செய்ய முடியாதே. அடுத்து பணியாளர்கள் ஒதுக்கீடும் (resource allocation) செய்வர்.

 

மொத்த திட்டத்துக்கும் இவ்வாறான எல்லா ஆய்வுகளையும் முடித்து திட்ட மேலாண்மை மென்பொருளில் உள்ளிட்ட பின், திட்டத்தை எப்பொழுது முடிக்க இயலும் என்று தெரிய வரும். இன்னும் விரைவில் முடிக்க வேண்டுமென்றால் பணிகளை கூடியவரை மாற்றியமைத்துப் பார்க்கலாம். அப்படியும் ஆகாவிட்டால் மேலும் பணியாளர்களை ஒதுக்கீடு செய்ய வேண்டியிருக்கும்.

 

வேலை நடக்கும் போது கான்ட் (Gantt) வரைபடம் ஒவ்வொரு பணிக்கும் தொடங்கும் தேதியையும் முடிக்கும் தேதியையும் காட்டும். மற்றும் யார் எந்த வேலையை செய்ய வேண்டும், அந்த வேலையை ஆரம்பிக்கும் முன் மற்ற எந்த வேலைகள் முடிந்திருக்க வேண்டும் என்றும் காட்டும். பணிகளின் சதவீத-முழுமையை நிழல் கோடிட்டுக் காட்டும். தற்போதைய அட்டவணை நிலையை “இன்று” என ஒரு செங்குத்து கோடிட்டுக் காட்டும்.

 

en.wikipedia.org/wiki/File:Pert_example_gantt_chart.gif

 

ஒரு வாரத்தில் நூற்றுக்கணக்கான பணிகள் நடக்கும்போது ஒவ்வொன்றாக ஆச்சா, ஆச்சா என்று பார்க்க வேண்டியதில்லை. எந்த 4 அல்லது 5 பணிகள் ஆகவில்லையோ அதைமட்டும் ஏன் ஆகவில்லை, என்ன செய்து விட்டதைப்பிடிக்கலாம் என்று பார்க்கவேண்டும். மேலும் அம்மாதிரி பணிகள் திரும்பவும் தாமதம் ஆவதை எப்படித் தவிர்க்கலாம் என்று பார்ப்பதும் மிக முக்கியம். இதை விதிவிலக்குகளை கவனிக்கும் மேலாண்மை (Management by Exception) என்று கூறுகிறோம்.

 

அருவி செயல்முறையில் ஒரு திட்டம் ஆரம்பித்த பின் மாற்றங்கள் செய்வது கடினம். அறவே முடியாதென்று சொல்லவில்லை. ஆனால் சில நேரங்களில் சிறிய மாற்றங்கள் கூட தொடர் விளைவுகளை ஏற்படுத்தும். இதைக் கையாளுவதற்கு திட்ட மேலாளர் பல உறுப்பினர்களைக் கலந்தாலோசிக்க வேண்டி வரலாம். அந்த மாற்றங்கள் செய்வதற்கான செலவையும் எளிதில் மதிப்பிட இயலாது. மேலும் மாற்றங்களின் செயற்பரப்பை பொருத்து பல மட்டங்களில் அனுமதி வாங்க வேண்டியிருக்கலாம். ஆக அருவி செயல்முறை சீட்டுக்கட்டு வீடு போன்றது. கட்டிய பின் கீழேயுள்ள ஒரு சீட்டை மட்டும் உருவி மாற்ற வேண்டுமென்றால் அது எளிதில் ஆகாது.

 

அருவி செயல்முறை எதற்குமே பயன்படாது என்று சொல்லவில்லை. நீங்கள் விண்வெளித் திட்டத்துக்கு மென்பொருள் எழுதப்போகிறீர்கள் என்றால், அருவி செயல்முறையே அதற்கு உகந்தது. நாம் அன்றாடம் செய்யும் வணிக, இணைய, அலைபேசி செயலிகள் போன்ற மென்பொருள் திட்டங்களுக்கு அது ஏற்றது அல்ல.

அருவி செயல்முறையின் முதல் இரண்டு கட்டங்களுக்கு, அதாவது தேவைப்பட்டியல் திரட்டுதல் மற்றும் வடிவமைத்தல், மொத்த திட்ட நேரத்தில் 20 முதல் 40% நேரம் எடுக்கும். எடுத்துக்காட்டாக ஒரு திட்டப்பணிக்கு மொத்தம் ஒரு வருடம் ஆகும் என்று வைத்துக்கொள்வோம். முதல் 3 முதல் 5 மாதங்கள் முடிந்த பின் ஒப்பந்தப்படி வாடிக்கையாளருக்கு ஒரு அடுக்கு ஆவணங்கள் அனுப்பி இருப்பீர்கள். வாடிக்கையாளரும் 40 முதல் 60% பண வழங்கீடு செய்திருப்பார்கள். ஆனால் ஒற்றை வரி கூட நிரல் எழுதியிருக்க மாட்டீர்கள். அப்படி ஒருக்கால் நீங்கள் ஏதாவது எழுதியிருந்தாலும் வாடிக்கையாளர் பார்த்திருக்க மாட்டார்கள், பார்க்கவும் வழியில்லை!