Agile/Scrum பற்றி தொடர் கட்டுரை – 10
“செய்யாத வேலையை முடிந்த அளவுக்கு அதிகப்படுத்தும் கலை, இன்றியமையாதது.” மென்பொருள் உருவாக்குவதற்கான கொள்கை விளக்க அறிக்கையுடன் (Agile Manifesto) வெளியிட்ட 12 கோட்பாடுகளில் ஒன்று இது.
இது விநோதமாக இல்லை? இவர்கள் சோம்பேறித்தனத்தை ஊக்குவிக்கிறார்கள் போல் அல்லவா தோன்றுகிறது! ஆனால் இதன் அர்த்தம் அதுவல்ல. பின்னால் தேவைப்படலாம் என்று வேலையை இழுத்துப் போட்டுகொண்டு செய்யாதீர்கள். அது தேவைப்படாமல் போகலாம். எடுத்துக்காட்டாக You Aren’t Gonna Need It (Yagni) “இது உங்களுக்குத் தேவைப்படாது” என்பது அதீத நிரலாக்கத்தில் ஒரு கொள்கை.
கென்ட் பெக் (Kent Beck) – உடன் 1996-ல் மென்பொருள் திட்டத்தில் வேலை செய்து அதீத நிரலாக்கம் உருவாக்க உதவியவர் ரான் ஜெஃப்ரீஸ் (Ron Jeffries). அவர் எடுத்துக்காட்டுகளுடன் மேற்கண்ட கொள்கையை விளக்குகிறார், “பெரும்பாலும் நீங்கள் நிரல் எழுதிக் கொண்டிருக்கும் போது உங்கள் மனதுக்குள் நமக்கு இன்னது பின்னால் தேவைப்படும் என்று தோன்றும். இந்த உந்துதலுக்கு எப்பொழுதும் செவிமடுக்காதீர்கள். அதாவது நிரலாளர்கள் எந்த செயல்பாட்டையும் அது அவசியம் தேவைப்படும் போதுதான் செய்ய வேண்டும். அது பின்னால் தேவைப்படலாம் என்று எதிர்பார்த்து முன்னேற்பாடாக செய்து வைத்துக்கொள்ளக் கூடாது.” இது இன்னும் விநோதமாக இல்லை? வேலையைத் தள்ளிப்போடும் குணத்தை ஊக்குவிக்கிறார்கள் போல் அல்லவா தோன்றுகிறது! வந்தபின் கவலைப்படுவதை விட வருமுன் காப்பது மேல் அல்லவா?
கென்ட் பெக் (Kent Beck) – உடன் சேர்ந்து 1999-ல் Refactoring: Improving the Design of Existing Code என்ற புத்தகத்தை எழுதிய மார்ட்டின் ஃபௌலர் (Martin Fowler) ஏனென்று மேலும் விளக்குகிறார், “XP-ன் மற்ற பல கொள்கைகள் போலவே, அது 90 களின் இறுதியில் மென்பொருள் பொறியியலில் பரவலாக நம்பப்பட்ட கொள்கைகளுக்கு மிகவும் மாறாகத்தான் இருந்தது. கவனமாக முன் திட்டமிடல் மென்பொருள் உருவாக்குவதற்கு முக்கியம் என்று மிக அதிகமான உந்துதல் அந்த நேரத்தில் இருந்தது. பெரிய அம்சங்களில்தான் Yagni நன்றாகத் தெரியும், ஆனால் நீங்கள் சிறிய விஷயங்களிலும் இதை அடிக்கடி பார்க்க முடியும். சில சிறிய Yagni முடிவுகள் திட்ட மேலாண்மையின் கவனத்திற்கே வராது. ஒரு நிரலாளர் விரைவில் தேவைப்படலாம் என்று நினைத்து ஒரு சிறிய விஷயத்தில் எளிதாக ஒரு மணி நேரம் செலவிடக்கூடும். இம்மாதிரி சிறிய Yagni முடிவுகள் நிறையச் செய்தால் நிரலில் சிக்கலை கணிசமாகக் குறைப்பது மட்டுமல்லாமல் அவசரமாகத் தேவையான அம்சங்களை சீக்கிரம் முடித்து வெளியிடவும் இயலும்.
ஆனால் தேவைப்பட்டபோது நிரலை மாற்றுவது எளிதாக இருந்தால்தான் Yagni ஒரு சாத்தியமான உத்தி ஆகும். இது சாத்தியமாவதற்கு, நீங்கள் ஓரலகு சோதனைகள் எழுதி, சோதனைத் தொகுப்பு ஓட்டுவதற்குத் தயாராக உங்கள் கையில் இருக்க வேண்டும். மற்றும் தொடர் ஒருங்கிணைப்பு செய்தலும் அவசியம்”.
இது இப்படி இருக்க, அருவி செயல்முறையில் திட்டம் ஆரம்பித்த பின் ஒரு தேவையை மாற்றவோ அல்லது சேர்க்கவோ நீங்கள் முயற்சி செய்ததுண்டா? ஒருக்கால் நீங்கள் முயற்சி செய்திருந்தால் அது எவ்வளவு தலைவலியான வேலை என்று உங்களுக்குத் தெரிந்திருக்க வாய்ப்பு உண்டு. இந்தக் காரணத்தினால் பயனர்கள் தங்கள் தேவைகளைப் பட்டியலிட ஒரே ஒரு வாய்ப்பு மட்டும்தான் கிடைக்கும் என்று நினைக்கிறார்கள். ஆரம்பத்திலேயே குறைந்தபட்ச வெளியீட்டுக்கு மேல் மிக அதிகமாகத் தேவைகளைச் சேர்க்கிறார்கள். இதனால் என்ன பிரச்சினைகள் ஏற்படுகின்றன என்று பார்ப்போம்.
-
நான்கு நிறுவனங்களில் அவர்களே செய்து பயன்படுத்தும் திட்டங்களில் எடுத்த கணக்கெடுப்பில் 64 சதவீதம் அம்சங்கள் “எப்போதாவது பயன்படுத்தப்படுகிறது அல்லது பயன்படுத்துவதே இல்லை” என்று தெரிய வந்தது.
-
டூபாண்ட் நிறுவனத்தில் செய்த ஆய்வில் 25% அம்சங்கள் மட்டும்தான் உண்மையிலேயே தேவை என்று தெரிய வந்தது.
-
இங்கிலாந்தில் ஒரு பெரிய நிறுவனத்தில் 10 ஆண்டுகளாக பயன்படுத்திய நிரலியில் ஒரு ஆய்வு செய்தனர். ஆய்வின்படி சுமார் 10% -க்கு மேலான அம்சங்கள் ஒருபோதும் பயன்படுத்தவில்லை என்று தெரிய வந்தது. மற்றொரு 14% அம்சங்கள் 10 ஆண்டுகளில் ஒரே ஒரு தடவை மட்டுமே பயன்படுத்தப்பட்டுள்ளன. அடுத்த 25% அம்சங்கள் ஒரு டஜனுக்கும் குறைவான முறைகளே பயன்படுத்தப்பட்டுள்ளன. மொத்தத்தில், அமைப்பில் கிட்டத்தட்ட பாதி அம்சங்கள் பயன்படுத்தவே இல்லை அல்லது ஆடிக்கு ஒரு முறை, அமாவாசைக்கு ஒரு முறைதான் பயன்படுத்தப்பட்டன.
மேலும் பயனர்கள் ஒரு அம்சம் தேவை என்று பட்டியல் தயார் செய்யும்போது அவர்களுக்கு அந்த அம்சத்தின் விலை என்ன என்றே தெரியாது. விற்பனையாளர்களும் ஒவ்வொரு அம்சத்துக்கும் தனித்தனியாக விலை இன்னது என்று பிரித்துச் சொல்வதில்லை. தனித்தனியாக விலை தெரியாமல் பட்டியலுக்கு மொத்த விலை மட்டும் கேட்டு யாராவது சாமான் வாங்குவது உண்டா?
ஆக, பின்னால் கேட்பது பிரச்சினை என்றும் மேலும் விலை தெரியாமலும் பயனர்கள் சில அம்சங்களைக் கேட்க, ஒருக்கால் தேவைப்படலாம் என உருவாக்குநர்கள் சில சட்டகங்கள் கட்ட, அருவி செயல்முறையில் கண்ணுக்குத் தெரியாமல் தேவையற்ற வேலைகள் பல செய்கிறோம்.
மொய்திரள் செயல்முறையில் தயாரிப்பு உரிமையாளர் வேலைகளை வரிசைப்படுத்தும் போது அதன் மதிப்பீட்டைப் பார்த்து, செய்யும் செலவுக்கு அதிக பயன் தரும் வேலைகளுக்கு முன்னுரிமை தர முடிகிறது. தேவையற்ற அம்சங்களை செய்தால் குறுவோட்டம் முடிந்தவுடன் பங்குதாரர்கள் பார்த்து கேள்வி எழுப்புவார்கள். மேலும் நீங்கள் XP பொறியியல் நடைமுறைகளான ஓரலகு சோதிப்புகள் மற்றும் தொடர் ஒருங்கிணைப்பு செய்தல் ஆகியவற்றை பின்பற்றினால் உங்களால் தேவைப்பட்டபோது நிரலை எளிதில் மாற்றியமைக்க இயலும். ஒருக்கால் தேவைப்படலாம் என முன்னாலேயே செய்து வைத்துக்கொள்ள வேண்டிய அவசியமில்லை.
– இரா. அசோகன் ( ashokramach@gmail.com )
மேலும் இந்த தொடரில் வந்த கட்டுரைகளை வாசிக்க : www.kaniyam.com/category/agile/